Le 27 août 09 à 09:11, Joel E. Denny a écrit :
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]]);
} <*> <>
Yes, indeed. But note that you are using %printer conveniently since
you assume that the message is to be sent to the console. If we're to
send it to a GUI, to syslog, whatever, we don't have a nice means to
use %printer. This is a pity. I would have preferred to have this
%error-report in charge of building the error message, and then
another function, yyerror, to be in charge of reporting the message.
As is the case today with yysyntax_error vs. yyerror.
No problem for C++, and I guess neither for Java.
Inappropriate design for C :( Actually, the flaw is arguably in C
itself, too bad there is no standard open_memstream, as provided by
the GNU Libc :(
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.
I don't understand how yyunexpected_value_printer would be different
from merely using %printer as provided by the user. So actually just
yyvalue_printer.
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);
} <*> <>
That's nice, indeed.
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.
Agreed.