|LEX and YACC, jeff & mutt arthur@lgc.UUCP (1989-11-02)|
|Re: LEX and YACC, jeff & mutt firstname.lastname@example.org (1989-11-03)|
|Re: LEX and YACC, jeff & mutt email@example.com (1989-11-04)|
|Re: LEX and YACC, jeff & mutt joshua@athertn.Atherton.COM (1989-11-07)|
|Re: LEX and YACC, jeff & mutt firstname.lastname@example.org (1989-11-08)|
|From:||joshua@athertn.Atherton.COM (Flame Bait)|
|Keywords:||YACC, error recovery|
|Date:||7 Nov 89 19:53:13 GMT|
|Organization:||Atherton Technology, Sunnyvale, CA|
In article <201@lgc.UUCP> arthur@lgc.UUCP (arthur) writes:
>If someone were to ask you for the reason/s why you wrote your SQL II
>(BNF as given by ANSI) interpreter by way of recursive descent
>parsing, as opposed to simply using tools like LEX and YACC, what
>would you say ?....
I would say that I made a mistake.
>I can only think of such obvious reasons as :
>1. better error handling ( of course, you have total control over
> what you will do with silly syntactic or semantic errors - blow
> them out of the system....)
I've always thought that this was true in theory, but false in practice.
In theory, it is possible to give better error handling in recursive
descent parsers, but in practice their error handling is usually worse
(or not better than) YACC parsers.
Two relevant stories:
When I was in school, I was part of a two person team which wrote a
compiler for most of C. It took me about two evenings of reading and
one evening of coding to add basic error handing. I'm sure that if I
had put a week or a month into it, I could have come up with better
error messages and recovery.
When I graduated, I maintained a compiler for an expert system shell,
which was recursive descent. Its error messages were terrible, and
generating them took up a fair about of code.
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.
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.
Given a file with four errors (on lines 23 30, 45 and 108), YACC based
parsers tend to give messages like this:
syntax error line 23
syntax error line 23
syntax error line 30
syntax error line 31
syntax error line 45
syntax error line 108
6 errors, so no code generated
While recursive descent tend to give error messages like this:
missing '[' line 23
I'd much rather have all the errors, than a little more detail with one
Joshua Levy email@example.com home:(415)968-3718
Return to the
Search the comp.compilers archives again.