>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Akim Demaille <[EMAIL PROTECTED]> writes: >> This feature was removed from several versions of Bison, restored >> by you on Christmas Eve 2002. In the meantime, no one complained. > Actually they did complain; that's why I changed it back. > Here's the complaint that prompted me to restore the feature: > <http://lists.gnu.org/archive/html/bug-bison/2002-12/msg00004.html>. > According to > <http://lists.gnu.org/archive/html/bison-patches/2002-12/msg00015.html>, > others also complained. Thanks for the pointers (and reminders). But I don't agree with your analysis here: the complaint is to have a similar feature, not this syntax. My grief is against the syntax. I would prefer by far to accept an identifier here. > The Bison versions that you're referring to (namely, 1.50 and 1.75) > were widely avoided due to backward-compatibility problems. Agreed. >> I don't think that [OpenBSD] counts. > I don't see why not. The implementation in OpenBSD is quite a bit > different from that of today's Bison. Last time I read its code (couple of years ago, agreed), the parser was still the same. > At this point it's pretty much an independent implementation > (partly because the OpenBSD folks hate GNU-licensed code). Agreed, but I was referring to the common ancestor byacc and bison had. They both inherited its parser, together with this "feature". >> I care about compatibility, but I'm more interest in gaining new >> users thanks to new features rather that keeping users of old stuff. > Sorry, I don't see the connection. What does the proposed change have > to do with adding new features, if you consider the Bison user's point > of view? I was referring to the fact that the whole machinery that was implemented in the scanner was precisely prompted by this troublesome %union. As a result, using BRACED_CODE elsewhere became much harder, which defeats the whole point of using a Bison grammar. >> And in the present case I'm not asking for the removal of the >> feature, but to make it what it should be: either rational or >> context free. > Sorry, I don't understand what you mean by "rational" and "context > free"? Are you talking about internal implementation details? Not exact, although arguably you could strip this down to implementation details since rational languages are context-free languages. To re-state my position, I'm dislike the *syntax* of this feature because it is neither lexical (i.e., a plain regexp), nor syntactic (i.e., a rule in the grammar). As a result, as a "feature", we accept weird input such as %union "{" { we reject things like %union MACRO_THAT_THROWS_AWAY_ITS_ARGUMENT({) { and fail to report unclosed parens in %union PREFIX(stype { So to my eyes, as it stands today the syntax of the feature is ill-designed. If we want to make it wide opened to weird stuff, then let's make it lexical, and that's my proposal. Honestly, I dislike this very much, first because it's ugly, and second because I fail to see how it would scale to other language. The other possibility, the one I prefer, is to make it syntactic but more restricted: accept a single optional ID in the grammar (then of course we have no problems with comments). *If* someone, someday, comes with a bigger need, then let's find a syntax that fits ours, say %union-tag %{ My big meaningful tag %}; %union { int foo; };
