|Re: Recursive-descent C parser WANTED email@example.com (1992-02-27)|
|Re: Recursive-descent C parser WANTED firstname.lastname@example.org (1992-02-27)|
|Re: Recursive-descent C parser WANTED email@example.com (1992-02-27)|
|Re: Recursive-descent C parser WANTED firstname.lastname@example.org (1992-03-04)|
|From:||email@example.com (Doug Merritt)|
|Keywords:||yacc, design, errors|
|Organization:||Netcom - Online Communication Services (408 241-9760 guest)|
|Date:||Thu, 27 Feb 92 01:40:38 GMT|
In article <1342@dms.UUCP> albaugh@dms.UUCP (Mike Albaugh) writes:
> Anyway, while such programs [Yacc/Lex/Bison/Flex] are "cool", they
>leave much to be desired in the area of error recovery, just the area
>where it is pretty simple to get a naive recursive descent parser to help
Adding error actions to Yacc grammars is not all that different from
adding error actions to recursive descent parsers. And in both cases
you're not likely to end up with very good error recovery until you've
hand collected many, many instances of real world errors and done
considerable work at sticking per-case reporting & recovery back into the
The added bonus to parser generators is that it is possible to add
variations on automated Graham-Rhodes error recovery to them, although in
the case of Yacc it takes an awful lot of work at reverse engineering its
tables, and some cases can't be handled due to info thrown away. (This is
what eyacc corrected for the narrow case of Berkeley Pascal.)
I haven't tried it for Bison; it would very likely be much easier there
than it is in Yacc.
You still want to optimize error reporting and recovery by hand, but it's
preferable for there to be an automatic default for the cases not handled
by hand-crafted error actions.
I suppose handling recursive descent might be considered more transparent
for the uninitiated.
Doug Merritt Preferred: firstname.lastname@example.org (or: email@example.com)
Return to the
Search the comp.compilers archives again.