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.