On 19 Jun 2006, at 07:49, Paul Eggert wrote:
In this particular case, since it's not too much trouble, let's worry
it, since we want Bison to be a drop-in replacement for BSD Yacc (even
for careless users :-).
If we want to set the user really free, then let's extend the grammar
with more than just ID, for instance a STRING, or even BRACED_CODE.
I don't see why that would be useful, and in the case of BRACED_CODE
it might even lead to weird behavior by Bison if the user forgets the
second % in "%union { ... } %{ .... %}". Since this is purely for
compatibility I think that all we really need to support is what's
used by BSD Yacc + C grammars, or perhaps BSD Yacc + C++ if some
people actually use that combination. If you think it unlikely that
C++ programers use "%union foo::bar {...}" then let's just support
single identifiers; that should be enough.
First, if the question is of just giving the implemented C++ 'union'
a name, I think that, when using the C++ 'namespace' construction,
one has to write:
namespace <name1> {
...
union <name2> {....};
...
}
to get the name1::name2 name. Thus, it is not needed as a part of %
union.
Second, as a preparation for other languages, it suffices that
%union <label> {...};
defines a M4 macro name derived from <label>, because then, when the
code placemenety version of %define becomes ready, one can write
%define <label> {<code>}
Or, if Bison always defines a macro say UNION_NAME, one can write:
%union {...};
%define UNION_NAME {<code>}
This simplifies the implementation of the Bison .y grammr.
Hans Aberg
