Re: Error reporting, was Infinite look ahead required by C++?

On Sat, 13 Feb 2010 18:24:28 -0700, wclodius@los-alamos.net (William
Clodius) wrote:


>Further
>for such grammars there there is almost always a limited number of
>productions possible and it is reasonable to give messages of the form
>"expexted ..., but ... was found.'" These are intrinsically not
>characteristics to be expected of general LR(k) grammars.


In LR(1), it is *easy* to give a message of the form "expected one of
<token list>, but <token> was found." - the set of possible next
tokens is part of the description of each state, and this can easily
be traced back to a set of productions (or else the parser could never
know when/what to reduce).


Yacc and Bison don't support reporting errors in this form AFAIK, but
the tool isn't the same as the algorithm the tool uses.


For generalised LR, of course, the picture is a bit more complex - but
something like this could still be done - just report the rightmost
location where your last parses were exhausted and base your message
on the set of states that occurred at that point (either the cases
where backtracking was triggered at that point, or the cases for the
last few rejected stack-duplicates).


The problem isn't the parsing technology, but the language itself. If
the language is ambiguous enough to need generalised LR, then at the
point of the *real* error, no error may be detected because there are
alternative parses yet to be rejected. When those last possibilities
are exhausted so that a syntax error is proved, the parser may have
gone quite some distance past the real problem, making the cause
difficult to trace irrespective of how the diagnostic is worded.

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