[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison and $ (dollarsign) token at the end
From: |
Hans Aberg |
Subject: |
Re: Bison and $ (dollarsign) token at the end |
Date: |
Tue, 9 Jul 2002 20:28:12 +0200 |
At 14:20 +0200 2002/07/09, Akim Demaille wrote:
>Hans> Here, "error" has a normal name, whereas there are two corny
>Hans> names "$", "$undefined.". These names are not used for anything
>Hans> but to write error messages.
>
>And traces (YYDEBUG).
Well, for printing only, not for anything that might affect the actual parsing.
>Hans> I think one could take some more descriptive, better looking,
>Hans> userfriendly names, like "end-token" "undefined" "undefined
>Hans> token"
>
>Hm, I think the point of the $ business is to insist on the fact that
>these are internal symbols, not reachable by the user: one cannot use
>$ or $undefined in the grammar, while error is allowed.
Quite, clearly. But it looks awful in print. And it does not explain why
"$undefined." should end with a dot.
The distinction between internal and grammar symbols are only important to
the one writing the grammar: To the user of the parser, one should supply
as much helpful information one can get.
Therefore I think a printout like
Expected end-token
Expected <end-token>
is more helpful than any of
Expected $
Expected $end
And
Error: undefined character 'a'
Error: undefined token number
should be more helpful than merely
Error: undefined
-- Even thought you do not like the fact that characters are usable in the
grammar, people do use it, and it is a supported Bison feature. So
therefore I think one must draw the consequences, and improve the function
when possible.
>Hans> Perhaps one should even have macros for these names (say
>Hans> YYEND_TOKEN_NAME, YYUNDEFINED_TOKEN_NAME), so that they can be
>Hans> changed at will.
>
>This is already the case of $:
>
>%token YYEOF 0 "end of file"
Oops, the name YYEOF is formally wrong: It is not end of file, not even end
of tokens, but _the_ end token added by the parsing algorithm. :-)
>The question is really wrt the internal, out of user name space,
>name.
Thank you for the info.
Hans Aberg