Re: Bison and $ (dollarsign) token at the end

[Hans Aberg]

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