Re: lalr1.cc: use %printer in the syntax error messages

[Joel E. Denny]

On Wed, 26 Aug 2009, Akim Demaille wrote:

> So I think that what we really need is to open yysyntax_error to the user.  We
> should provide the user with the lookahead, the (full) list of expected
> tokens, the location, and *she* should forge the error message she wants.

That makes sense to me.  Some time ago, we discussed adding a 
%error-report declaration in order to avoid the fluctuating yyerror 
prototype.  The user could access all these elements from that.  For C, it 
might be:

  %error-report {
    char const *loc = yylocation_to_string (@$);
    fprintf (stderr, "%s: %s\n", loc, yymessage);
    fprintf (stderr, "%s: unexpected %s", loc, yytname[yyunexpected]);
    if (yyunexpected_is_typed)
      {
        fprintf (stderr, " with value "); 
        yyunexpected_value_printer (stderr);
      }
    fprintf (stderr, "\n%s: expected any of:\n", loc);
    for (int i = 0; i < yynexpected; ++i)
      fprintf (stderr, "%s:   %s\n, loc, yytname[yyexpected[i]]);
  } <*> <>

The yyunexpected_value_printer keeps this code generic.  The user could 
push more of this code into individual %printer's to tailor the message 
more for each symbol or type, but that can't go too far if %printer is 
still going to be useful for parser tracing.

If the user wants to tailor error reporting rather than value printing for 
each symbol or type, the user might want to access $$ directly in 
%error-report.  In that case, he'll have to specify a more specific list 
of symbols and types at the end of his %error-report declaration.

For the user who is fine with Bison's traditional verbose error messages 
but still wants to avoid the yyerror prototype confusion, he could write:

  %error-report {
    fprintf (stderr, "%s\n", yymessage_verbose);
  } <*> <>

We could probably just deprecate yyerror (not for Yacc of course) and 
%error-verbose and tell the users to just choose between yymessage and 
yymessage_verbose in their %error-report.

Bison would probably need to complain if the user didn't provide enough 
%error-report's to cover all symbols.  Or Bison could just invoke yyerror 
for the remainder, inducing a compiler complaint if the user didn't 
provide yyerror.

> (Oh, and by the way, the error messages presented here are completely wrong.
> I have no idea why they are, and I hoped that Joel's changes would solve them,
> but they do not: there are many many other tokens that can follow the initial
> float, arithmetical operators for instance.)

I've checked it out, and the problem is fixed by canonical LR.

However, when you try that on an input like "1 2", you're going to find 
that the expected list disappears altogether.  The problem is that the 
correct expected list is too long for the translatable strings that we've 
prepared, and so the parser abandons the list.  I think that's an 
unfortunate sacrifice to make for internationalization.