[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: [PATCH] Do not allow identifiers that start with a negative number.
Date: Sat, 08 Jan 2011 20:20:11 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101208 Thunderbird/3.1.7

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,


is the same as


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


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.

reply via email to

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