|[4 earlier articles]|
|Re: .NET Compiler for Interactive Fiction email@example.com (2003-03-16)|
|Re: .NET Compiler for Interactive Fiction JeffKenton@attbi.com (Jeff Kenton) (2003-04-05)|
|Re: .NET Compiler for Interactive Fiction firstname.lastname@example.org (Joachim Durchholz) (2003-04-13)|
|Re: parsing, was .NET Compiler for Interactive Fiction email@example.com (Ralph P. Boland) (2003-04-15)|
|Re: parsing, was .NET Compiler for Interactive Fiction bobduff@shell01.TheWorld.com (Robert A Duff) (2003-04-20)|
|Re: simple vs. complex parsers firstname.lastname@example.org (Chris F Clark) (2003-04-27)|
|Re: simple vs. complex parsers email@example.com (Joachim Durchholz) (2003-05-05)|
|Re: simple vs. complex parsers bobduff@shell01.TheWorld.com (Robert A Duff) (2003-05-15)|
|Re: simple vs. complex parsers cfc@shell01.TheWorld.com (Chris F Clark) (2003-05-18)|
|Re: simple vs. complex parsers firstname.lastname@example.org (Sylvain Schmitz) (2003-05-18)|
|Re: simple vs. complex parsers email@example.com (Lieven Marchand) (2003-05-18)|
|Re: simple vs. complex parsers firstname.lastname@example.org (2003-05-18)|
|Re: simple vs. complex parsers email@example.com (2003-05-23)|
|[2 later articles]|
|From:||Joachim Durchholz <firstname.lastname@example.org>|
|Date:||5 May 2003 23:38:03 -0400|
|References:||03-02-125 03-02-147 03-03-043 03-03-061 03-03-103 03-04-006 03-04-028 03-04-046 03-04-066 03-04-116|
|Posted-Date:||05 May 2003 23:38:03 EDT|
Chris F Clark wrote:
> The ideal goal is a parser generator that can take "any" grammar
> infer what language it is intended to describe and create a correct
> parser. That goal is unattainable,
It's not only attainable, it's already attained: Use a GLR (aka
Tomita) parser generator. It will handle any context-free grammar.
The only downside is that the parser generator won't tell you whether
your grammar is ambiguous. Nothing that a separate "grammar checker"
tool couldn't handle (that checker would need assistance from the
grammar writer, since the problem is undecidable in general).
Separating ambiguity checking from parsing would have the charm that the
grammar rewrites to do the checking could be separated from parsing.
This, in turn, would have two advantages:
First, errors during the grammar rewrite have less of an impact (a parse
may fail due to ambiguities - usually something that the application
programmer can fix by adding a parenthese or semicolon where needed).
Second, grammar rewrites for an LR parser generator tend to obscure the
true language structure, making the job of the AST decorator much
harder. If the rewrite is just for purposes of establishing unambiguity,
the rewrite is allowed to be as ugly, contorted, and computer-assisted
as desired, it won't make the life of future compiler writers miserable.
Currently looking for a new job.
Return to the
Search the comp.compilers archives again.