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. >> And if so, >> why should "--39--" *not* be an identifier? > > Who says it shouldn't? The rule you proposed above says it shouldn't. >> 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. 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: the problem of the above suggestion (which apparently is buggy) is another. 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. 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.