bug-bison
[Top][All Lists]
Advanced

[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: Joel E. Denny
Subject: Re: [PATCH] Do not allow identifiers that start with a negative number.
Date: Thu, 27 Jan 2011 08:35:31 -0500 (EST)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

Hi all,

Thanks to everyone for their recent feedback.

On Wed, 26 Jan 2011, Akim Demaille wrote:

> Le 15 janv. 2011 à 22:50, Joel E. Denny a écrit :
> 
> 1.
> >  An identifier can be any sequence of letters, underscores, periods, 
> >  dashes, and digits that does not start with an integer (unsigned or 
> >  negative).
> 2.
> >  An identifier can be any sequence of letters, underscores, periods, 
> >  dashes, and digits that does not start with an integer or float 
> >  (unsigned or negative).
> 3.
> >  An identifier can be any sequence of letters, underscores, periods, 
> >  dashes, and digits that does not start with a digit or dash.
> 
> I dislike 2, and like 1 and 3 equally.

Based on yesterday's replies from Alex and Akim, it sounds like there's 
strong agreement to revert Paul Eggert's patch (bf3e44) rather than trying 
to apply additional patches on top of it.

After that, we need to go back to fixing the bugs in this thread.  Though 
I haven't tried it yet, it looks like the original bug reported by Paul 
Hilfinger (the loss of ".p" in "$-1.p") can be fixed by any of the 
numbered solutions above, but #3 has many advantages:

a. #3 also appears to solve the second bug in this thread (misinterpreting 
"-123" as "- 123").

b. Paul Eggert, Akim, and I are all fine with #3.  Of these three 
solutions, Paul Eggert seems happiest with #3.

c. The second most popular solution is #1 (I prefer it and Akim likes it 
as well as #3).  Fortunately, if we choose #3 now, we could later change 
our minds and move to #1 without backward compatibility problems because 
#1 permits a superset of the symbols permitted by #3.

Reverting Paul Eggert's patch, writing a patch to implement #3, 
documenting the change, and updating and extending the test suite should 
be straight-forward.  Unless someone else desires to do it (if so, let us 
know), I'll propose a patch, perhaps this weekend.  Then we can test that 
to be sure there are no other oversights.

> Let me go a bit further about this.

Akim, I appreciate all your feedback yesterday.  I want to comment on it, 
but I'm short on time this morning.  I'll try to reply soon.

reply via email to

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