[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Prefer error-verbose to error_verbose

From: Akim Demaille
Subject: Prefer error-verbose to error_verbose
Date: Wed, 15 Apr 2009 22:16:10 +0200

If we mean to support dashes in variables names, and we do, then something must be changed in the way we scan variable names, as currently they rely on the same lexical definition of "identifier" as the rule symbols do.

There are several ways to do that. One is to introduce a new token type, "ID_WITH_DASHES", and extend the following grammar rules:

| STRING { $$ = uniqstr_new ($1); }

That's straightforward. There is one interesting question about the user-visible name to use for ID_WITH_DASHES. It cannot be "identifier" since that's already used by ID, so should it be "variable", since ID_WITH_DASHES would be only used for variables? Not nice, we're giving some syntactic interpretation to a lexical entity without knowing yet how this "variable" is going to be used. And of course, the error message will differ depending whether there are dashes or not in the identifier (this is arguably a limitation in Bison's support for user-visible token strings, after all both ID and ID_WITH_DASHES could be mapped to "identifier" without any problems provided "identifier" is not used in the grammar itself).

I don't like too much this approach, I prefer simply welcoming dashes in the set of letters that can compose symbol names. Of course we would have to have warnings and errors in Yacc mode, but that should not be hard, we certainly have one well defined point by which we always pass to make a symbol name. I also like that identifiers and directives are only separated by %.

But what do others think?

There is one clear downside: named references. The period is already causing nasty issues when reading { .. $ .. }, introducing dashes will not improve the situation { .. $foo-bar .. }. I would stick to the principle that identifier in the action should stick to C symbols, that exclude dashes and periods, so this was { .. $[foo]- bar .. } "of course".

I have pushed my proposal (which does not include the warning) in candidates/define-error-verbose, whose patch is attached here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]