Re: recursive-descent error recovery

In article <651@ima.ISC.COM> decvax!utzoo!henry writes:
>> [I'd be interested in hearing what the recursive descent lexer feeds to the
>> parser when the input is something like a = b + ( ; -John]
>
>The basic approach in the lexer is (a) give the customer what he wants, and
>(b) if what he wants doesn't match what's in the input, apply some simple
>heuristics to try to resynchronize. Say we've just parsed the "b", so the
>parser knows we're in an expression that is part of a statement; here is
>the dialogue, slightly simplified:
>
[Relatively long dialog deleted...]


This seems like a pain. Recusrive descent with error recovery performed
by the higher level entity would seem to be simpler, namely because the
higher level entity knows more about what's going on. For example, suppose
the expression parser has just parsed the paren. The conversation then
proceeds as follows:


Expression Parser: Give me a token.
Lexical Analyzer: Okay, here's a semicolon.
EP: A semicolon?! I didn't expect one of these. I expected an
expression. Yo! User! I expected to see an expression after this
parenthese at line 124. Okay... Now I've told the user it screwed
up, let's recover from this sucker. The simplest thing to do, since
I'm in an expression, is to toss tokens until I get to a synchronizing
token like a semi. Hmmm... I've got a semi, so I'm now synchronized.
Okay. Let's tell our caller that we parsed an expression successfully.


Meanwhile... A while ago I suggested that one cannot write a reasonable
compiler using YACC. I got no response. So let me attempt to generate
some flames. I claim it is impossible to write a reasonable compiler
using YACC. I base this claim on the fact that while it is important
that a compiler produce a correct binary, it is nearly as important that
the compiler produce reasonable error messages. I further claim it is
impossible to produce reasonable error messages using YACC.


So flame me and tell me why I don't know what I'm talking about. I feel
the need for some edification...


But what about developing the | Chuck Simmons @ Amdahl
moon before we terraform Mars? | amdahl!chuck
[Just because nobody ever does good error recovery in yacc parsers doesn't
mean it's all that hard. What is hard is to figure out the right set of error
productions to add to the grammar to catch the sorts of errors that will
actually occur. Then there's the issue of what a good error message is. Some
people like things like "statement required ID, CPAREN, SEMI, BLURCH, or BLAH
but FNUMBER was encountered." Personally, I liked the ones in Fortran H which
sounded like pronouncements from a slightly disdainful robot: "IEH247I THE
STATEMENT CONTAINS A PROSCRIBED COMMON DECLARATION." -John]
--

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