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

[Paul Eggert]

On 01/08/2011 12:48 PM, Joel E. Denny wrote:

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

Yes, Bison experts can parse the code because they know all
the ins and outs of the rules.  But surely ordinary users will
be confused.  For example, if "--x" is an identifier, then
in C code

   $--x

is supposed to be parsed as "$" applied to the identifier "--x", but

   *--x

is supposed to be parsed as "*" applied to "--" applied to
the identifier "x".

This is the sort of confusion I am worried about.

> We already have such a syntax: $[B].  However, it's only required when 
> it's necessary

But there are two reasons it might be necessary, not just one.
One reason is to avoid bugs or problems in implementation.
The other reason, which is as important, is to avoid confusion
among users.  It is the latter reason that I am thinking about
here.  Even if notation is formally unambiguous, it still may
be unreasonably confusing.

I suggest that we allow the syntax $B only when B is a
valid C identifier, and require the square brackets otherwise.

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

Sorry, I'm not following this.  If the syntax is

id       -|({letter}|-({letter}|-))({letter}|[-0-9])*

then "x--" is a valid identifier, no?  And if it is valid,
then why isn't "$x--" parsed as "$" applied to the identifier
"x--"?

> It does allow "x".

Oh, sorry, I was wrong again, and you were right again.
I'm having a great deal of trouble parsing that regular expression,
so you may have to bear with me in yet another confusion of mine.
Whatever regular expression we come up with, obviously we
should document it (unconfusingly :-).