[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: glr: include the created header

From: Akim Demaille
Subject: Re: glr: include the created header
Date: Wed, 28 Jun 2006 20:59:32 +0200

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

:)  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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]