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

[Akim Demaille]

| 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.

Of course not.




| >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.

Right.


| 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.

You aim at the wrong target.  First, the error messages have to be
cleaned.  Then we can see how aliases can help.  Currently, anyway,
the messages, even with the assistance of the grammar writer, are far
from being perfect.  For instance:

        parse error: unexpected "number", expected "end of file"

should look like

        parse error: unexpected number, expected end of file

not matter the internal/external names.  It's the whole composition of
the error message that ought to be revisited.