Re: glr: include the created header

[Akim Demaille]

Le 28 juin 06 à 20:07, Paul Eggert a écrit :

> "Joel E. Denny" <address@hidden> writes:
>
> > Why was the ability to concatenate several %union's together added?
>
> I'm the guilty party on that.  As I recall, the problem was that Bison
> formerly had undefined behavior if you had multiple %unions (it
> generated garbage code), and I wanted it to do something more
> reasonable.  I didn't put a lot of thought into it, and I don't think
> anybody's really relying on it.  We shouldn't let this tail wag any
> dog.

:)  I think I understand the meaning, but that's the first time I
parse this saying (in French sayings are said to be "expressions"
(yep, same word as in English).  Parsing an expression reads even
better).

> Now that I think of it, "%union foo { ... } %union bar { ... }"
> probably generates garbage code even now.

No it does not: it gives the priority to the latest.  Just as
%define still does.  That's simply a matter of having muscle_define
catch redefinitions once for all.

> I guess we should simply
> disallow multiple %union, as C does.

Your patch is needed.  IMO it was just too soon, because nothing
else is ready, but some day we will need it.

> Stepping back from this a bit, I'm totally confused now by all the
> directives being proposed.

My proposal is based on two directives: %public goes into the header
(and of course %union belongs to %public), and %private does not.
I suggest that %{ ... %} be sugar for %public, Joel thinks %private
is more appropriate.

> Here's one idea to simplify things a bit.  How about if we say that
> "%union { ... }" is treated like:
>
>    %{
>      typedef union { ... } YYSTYPE;
>    %}

This is the semantics the user must see.  What we implement can be
different.  And because I'm in favor of (tamed) multiple %union,
I am still in favor of a split %public part *as an implementation
detail*.  I am against exposing this split thing to the user, the
order is way enough.