Re: [PATCH] Do not allow identifiers that start with a negative number.

[Joel E. Denny]

On Sat, 8 Jan 2011, Paul Eggert wrote:

> On 01/08/2011 11:59 AM, Joel E. Denny wrote:
> > On Sat, 8 Jan 2011, Paul Eggert wrote:
> > 
> >> On 01/08/2011 10:29 AM, Joel E. Denny wrote:
> >>> id       -|({letter}|-({letter}|-))({letter}|[-0-9])*
> >>
> >> Sorry, I guess I don't understand the point of this.
> >> Why should "---39---" be an identifier?
> > 
> > I thought we were adding the simple rule that an identifier cannot begin 
> > with a negative integer.  "---39---" does not begin with a negative 
> > integer.
> 
> That depends on how it is parsed.  If we are mentally parsing
> it using the rules of C, "---39---" starts with a "--" token,
> and then we have the same problem as before.

I'm mentally parsing it according to the rules of Bison.  "$-39-" already 
has a meaning, but "$--39--" and "$---39---" do not.

> >> And if so,
> >> why should "--39--" *not* be an identifier?
> > 
> > Who says it shouldn't?
> 
> The rule you proposed above says it shouldn't.

That's not true.  Try replacing the current definition of id with the one 
above, and you'll see that "--39--" is accepted.

> >> Can someone remind me why we're doing this?
> > 
> > It's consistent with other identifiers in Bison.
> 
> Sorry, now I'm lost.  The rule for "id" *is* the rule for
> identifiers in Bison, surely.

Sorry for the confusion.  I was referring to its use in directive names, 
variables, and values.

> What I'm asking is, why did we change the rule to allow "-"
> in identifiers, and to embed these identifiers into C and
> Java code, when this causes obvious problems?
> The issue that started this thread is one example of
> such a problem:

There was one problem beyond the issues already caused by ".", and it 
appears to be easy to fix.

> the problem of the above suggestion (which
> apparently is buggy) is another.

I see no bug.

> Perhaps we can take a step back here.  Why is it important
> that we allow the syntax $B in C code, where B is a Bison
> identifier?  If Bison identifiers are not the same as C
> identifiers, the resulting code will be hard to explain
> and to read.  Wouldn't it be better to require an escape
> syntax for these identifiers? Something like ${B}, or $"B",
> or $[B], or $(B), or etc.?  That will make it more obvious
> to the reader where the Bison identifier stops and the C code
> starts up again.

We already have such a syntax: $[B].  However, it's only required when 
it's necessary, and Alex has done a great job of producing very 
informative error messages when a user forgets the brackets.

> For example, when suppose we have the following code
> in a Bison + C parser:
> 
>     $x--;
> 
> Most programmers would expect this to subtract one from $x,
> not to compute the value of the identifier "x--" and then
> discard it.  If a programmer really wants to name their
> identifier "x--" they should write "${x--}" or something
> like that.

I agree, and that's already what the programmer has to do.