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

[Paul Eggert]

On 01/08/2011 03:19 PM, Joel E. Denny wrote:

> I thought we would simply extend the existing solution for unsigned
> integers to negative integers: never permit any identifier anywhere
> to begin with an unsigned or negative integer.

Yes, that was my proposal.  But at the time I didn't understand the
issues as well as I do now.  (Not that I fully understand it now....)

>> > I suggest that we allow the syntax $B only when B is a
>> > valid C identifier, and require the square brackets otherwise.
> I believe that almost perfectly describes the behavior on branch-2.5 and 
> master.  The only subtlety here is that, for example,
> 
>   $sym.field
> 
> is the same as
> 
>   $[sym].field
> 
> even if sym.field is a valid symbol name.

OK, thanks, but that's not really a subtlety: that's inherent to
the proposed solution.  So, if I'm understanding you correctly,

   $x--

is the same as

   $[x]--

for the same reason, even if "x--" is an identifier.  And, similarly,

   $--x

is invalid.

>> > "x--" is a valid identifier, no?
> Yes, it's valid.
> 
>> > And if it is valid,
>> > then why isn't "$x--" parsed as "$" applied to the identifier
>> > "x--"?
> Because Bison reparses the reference later to find "-" and ".".

Why does Bison need to reparse anything?  Bison can simply require,
when it's doing the lexical analysis for $FOO, that FOO be
a valid C identifier.  That is the essence of the above suggestion.
And it should be very easy to do, much easier than any reparsing.

> How about the following?  The manual currently says:
> 
>   Symbol names can contain letters, underscores, periods, dashes, and
>   (not at the beginning) digits.
> 
> Let's change that to:
> 
>   A symbol name can be any sequence of letters, underscores, periods, 
>   dashes, and digits that does not start with an integer (unsigned
>   or negative).
> 
> Is that clear enough?

It's clear for Bison identifiers per se, but it's not clear for
the $FOO syntax.  Is the constraint on the $FOO identifiers described
somewhere else?  Even if so, it should be alluded to here, so that
users know that C identifiers are in some sense "nicer" when choosing
symbol names, since they can be used in the $FOO syntax.