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

[Simon J. <sje...@bl...>]

Christian Schoenebeck wrote:

>Hi everybody!
>
>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
so the parser can be smaller and faster) and one fix (putting quotes 
around string literals
to repair a very large hole in an otherwise fairly tight spec).

>The reason why I left this naive approach of the 
>scanner/parser definition with all its ambiguities was the hope that we could 
>find and move to a good parser generator that doesn't have this annoying or 
>better say radical split between scanner and parser. That's the main problem 
>of these ambiguities, not the protocol definition itself.
>
Its not about the tools. Yes, there are parser generators that accept 
more general
grammars than yacc, eg Accent ( http://accent.compilertools.net ), but 
changing
to one of them wouldn't resolve either of these issues:

The Lex Tradeoff ~
If you don't think its a fair trade, you don't have to make it. Abandon 
lexical
analysis for keywords and Yacc can generate a purely syntactic parser that's
bigger and slower but can distinguish keywords from names by their position
in  the sentence. Switch to Accent? NO DIFFERENCE: You've still got exactly
the same choice of whether or not to speed things up by lexing first.

OK, maybe there's something out there that does something really clever,
like flipping between different lexers according to context. But they've
all got SOME notion of a lexical analysis phase, if only because...

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.

Simon Jenkins
(Bristol, UK)