Re: Yacc error recovery...

kaz@nt.com wrote:
>The normal way for a yacc-generated parser to recover using an ``error
>production'' of the form A -> error b is to keep reading tokens until
>a 'b' nonterminal is encountered, and then reduce by the production.
>
>This is not very satisfactory, since at times it would be nice to either
>insert tokens into the input stream, or even just have the input stream
>read up to, but not including 'b'. For example, 'b' could be the non-terminal
>'}', making it possible for the error recovery to read only until the end
>of the enclosing scope in a C-like language.
>
>Is there some yacc method for doing more flexible error recovery, preferrably
>one that works across the various compatible parser generators?
>
>I hate having a compiler fumble around after one parse error that could have
>been easily recovered from.


Many years ago, before there was a YACC port available I wrote an LALR
parser generator for VMS. At the time I had never used YACC but had
read descriptions of it in compiler books. The parser generator I
created would attempt to insert, delete, then replace in that order at
token before attempting YACC style error recovery. This system worked
quite well. In practice token error recovery was able to handle
almost all eroneous input.


Presumably you could write your own parser that could incorporate this
style of error recovery. Some YACCs such as Bison allow you to user a
paser of your own (some others do not). The problem is that you need
a little more information about your tokens than YACC supports.
Tokens such as ')' are suitable for this type of error recover while
symbols are not. Some tokens such as the traditional UMINUS that
never appear in the input stream clearly are not suitable. You need
to be able to define tokens that can be inserted and the order that
they should be tried.


John
--

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