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.
