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

Kaz Kylheku <kkylheku@gmail.com> writes:


> On 2010-02-15, Ira Baxter <idbaxter@semdesigns.com> wrote:
>> "Stephen Horne" <sh006d3592@blueyonder.co.uk> wrote in message
>>> On Sat, 13 Feb 2010 18:24:28 -0700, wclodius@los-alamos.net (William
>>> Clodius) wrote:
>>>
>>> In LR(1), it is *easy* to give a message of the form "expected one of
>>> <token list>, but <token> was found." -
>>>
>>> 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.
>>
>> One more reason not to use these tools, or at least get a groundswell
>> in favor of some open source person to integrate such error reporting.
>
> With error productions and yychar, you can indeed implement fairly
> friendly error messages which indicate context (what was being parsed,
> what might be expected next) and the problem (the token that was
> encountered instead).
>
> You can add error productions to the grammar, and there is a
> ``yychar'' variable which gives you the lookahead token. It's value is
> zero if the cause of the syntax error is a premature end of input.
>
> I have recent practical experience with this.


...
> Now obviously these are not messages of the form
> ``expected <token list> but found <token>''.
>
> There indeed doesn't appear to be a way in Yacc to access the state and
> transition info to be able to produce the list of tokens representing
> valid shifts.


It may not be available in the public documented interface, but the
information is there in the parser tables, once one figures out how to
dig it out. Of course, one of the issues (imho) with yacc and bison
(and also for lex and flex) is that the tables are presented with very
little documentation for understanding them. Not understanding them
ourselves is part of why we wrote Yacc++.


We also added a function display expected, that walks the (Yacc++)
tables and produce the desired list of expected tokens. In addition,
we documented a couple of the obvious customizations to the display
expected algorithm (which is an overridable member function) like
mapping keywords back to identifier for languages with non-reserved
words.


Hope this helps,
-Chris


******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------

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