Re: %union foo bar baz and others { ... }

[Akim Demaille]

 Paul> Akim Demaille <address@hidden> writes:
 >> The net result is that the sources are atrocious, error prone,
 >> intricate, while The Right Thing was elegant and did not hamper new
 >> extensions in Bison.

 Paul> If we're talking about the "%union foo {" change, I agree that it
 Paul> would be much nicer if we could do this in the parser than do it in
 Paul> the lexer.  The main reasons I did it in the lexer were (1) I don't
 Paul> know the syntax for C++ well, and some bug reports in this area were
 Paul> C++-related so I'd like to support whatever C++ needs, and that
 Paul> requires knowing the C++ grammar to do a parser-based change, and (2)
 Paul> Bison used to do it in the lexer, so I was sure that the change would
 Paul> fix the regression.

Hm, I thought I had already made clear that C++ wants the tag and the
type to be equal.

But the point is that anyway this feature is dubious.  I am not
convinced at all it should make it (back) into Bison.  And I don't
care what Solaris Yacc says about this.  It collides with future
extensions, might cause problems with --prefix etc.  This is just not
a good idea.

 Paul> I would favor further cleanups by supporting this extension in the
 Paul> parser rather than the lexer, but I'd like to know the answer to (1)
 Paul> before proposing such a cleanup.  I'd rather not simply reverse the
 Paul> patch, since I don't want to break backward compatibility without a
 Paul> compelling technical reason.  And so far, I haven't seen a reason that
 Paul> is compelling enough.  Certainly I don't want to unduly hamper future
 Paul> extensions, but I don't know what the extensions you are thinking of
 Paul> in this area so I don't know what would hamper them and what would
 Paul> not.

The only extension have in mind in this area is that multiple %union
should be allowed.  Add a form of inclusion, and you end up with a
form of modules for grammars.  Actually, even the very syntax of
%union is a failure, and imho, Lemon had it right: there is no reason
for the user to know the name of the fields.  But that's not
important.

In the present case I'm not inclined to include this feature because
even with an id, it will complicate the program for a no additional
feature: the very feature is provided by the language itself, so I see
no point in having it in addition on Bison.