Re: LEX and YACC, jeff & mutt

In article <14450@joshua.athertn.Atherton.COM> joshua@athertn.Atherton.COM (Flame Bait) writes:
>Recursive descent parsers are much harder to maintain than YACC parsers.
>(I've maintained a parser in each, both of which were written by others.)
>Recursive descent parsers always seem to grow little "ad hoc" extensions,
>and are a maintenance nightmare, while I find a YACC specification to be
>a good head start in understanding the code.


What you really mean is that *ad-hoc* RD parsers are hard to maintain.
Here we are using a parser-generator that takes a YACC-like notation
and generates a RD parser in C (in which each production compiles to a
procedure). The notation is the familiar "extended BNF", including +,
?, and *, so it's somewhat more readable than YACC.


We *need* our own parser generator because some of the langauges we
have to deal with (we're in the IC tester business) are nowhere near
LR(1). Also, the lexical structure tends to be context dependent,
i.e. a filename (which is not quoted) is not the same as an
identifier. RD parsers have no trouble dealing with this because they
always know what they're looking for.


Oh yes, of course the parser generator is written in itself. It took
a week (including design and debugging), including hand-compiling the
first version.


>YACC makes it easy to restart a parse from an error. This is worth the
>price of admission alone! Most recursive descent parsers seem to punt
>after the first error.


It is, however, possible to make a RD parser that recovers from
errors. It just takes more effort.


>Given a file with four errors (on lines 23 30, 45 and 108), YACC based
>parsers tend to give messages like this:
[long list of uninformative errors omitted]


This would be ok if all of the errors were real. On most *syntax*
errors (rather than semantic errors), YACC parsers get just as
confused as RD parsers, and continue spewing worthless error messages
until the compiler's error limit shuts them up.


>While recursive descent tend to give error messages like this:
> missing '[' line 23
> parsing aborted
>
>I'd much rather have all the errors, than a little more detail with one
>particular error.


I'd much rather have a fast enough compiler and fix errors one at a
time. This is unrelated to the parsing method used.
--
    Steve Savitzky | steve@arc.uucp | apple.com!arc!steve
    ADVANsoft Research Corp. | (408) 727-3357(w) / 294-6492(h)
    4301 Great America Parkway | #include<disclaimer.h>
    Santa Clara, CA 95054 | May the Source be with you!

Return to the comp.compilers page.
Search the comp.compilers archives again.