Re: [Linuxsampler-devel] parser generator (was: Latest CVS Commit)

[Christian S. <sch...@so...>]

Es geschah am Mittwoch, 23. Juni 2004 00:39 als Simon Jenkins schrieb:
> Christian Schoenebeck wrote:
> >I don't think I like all these tradeoffs in the protocol definition you're
> >discussing the last days. :)
>
> All of them? There was one tradeoff (disallowing key names that match
> keywords

Thats one of the tradeoffs I definitely don't like. Because the driver 
developer should be able to add any parameter name he wants for his device 
driver.

> so the parser can be smaller and faster) and one fix (putting quotes
> around string literals

Right, that was a relict, nothing against that of course.

> OK, maybe there's something out there that does something really clever,
> like flipping between different lexers according to context. But they've

That's what I meant. The parser should at least work in such way together with 
the scanner, so the scanner only feeds the parser with terminal symbols which 
are defined in current (that is most congruent) grammar rule. The interface 
between lex and yacc is of course too primitive to allow such things. But 
there are a lot of parser generators out there, so I still hope we can find 
one that can do that and maybe even supports BNF, means an abstract 
definition of the protocol.

> all got SOME notion of a lexical analysis phase, if only because...

Lexical analysis itself is not the problem.

> The String Problem ~
> can ONLY be resolved lexically!
>
> Think about it... the protocol carries arbitrary, user entered strings.
> How can
> any parser POSSIBLY know where one of these strings ends without a lexical
> clue of some sort? Whatever the parser saw that might signal the end of
> a string
> could just as easily be more characters that were part of the string...
> it would
> have to wait /forever/ before it was sure.

In our case the end of the wait would at least be the line feed character. But 
I agree that's not a good solution, so putting strings in apostrophes or 
quotes is far better from the parser's point of view.

CU
Christian