Re: glr: include the created header

[Akim Demaille]

>>> "Joel" == Joel E Denny <address@hidden> writes:

 > On Sat, 3 Dec 2005, Akim Demaille wrote:
 >> Le 3 déc. 05 à 02:44, Joel E. Denny a écrit :
 >> 
 >>> Did you intend for b4_pre_prologue to appear in
 >>> b4_shared_declarations? I didn't expect to see my prologues in my
 >>> header file.  This can lead to unexpected pollution of the
 >>> namespace of the #includer, and it's inconsistent with yacc.c at
 >>> least.
 >> 
 >> Yes I did, because the pre-prologue is expected to define what
 >> yystype needs, and the latter is export in the header file.  Actually,
 >> that's something I wish I could also change in yacc.c...

 > I can see the logic in this feature, but I think it's a bit cryptic. 
 > Even more confusing since it's inconsistent with yacc.c.

I would have like yacc.c to follow this pattern too.  I find this
logical.

 >> If you don't want them to be exported, they should probably be
 >> in the post-prologue.  Is that ok with you?

 > That's a problem because sometimes I either don't define %union or
 > I define it with #define YYSTYPE (in a header file with its
 > dependencies).  In those cases, is there any way to avoid having
 > all of my literal blocks dumped into the header file?

Bummer.  You are right, in this case the pre-prologue should be the
post-prologue.  Do you see a problem if that's implemented in Bison
that way?

 > Why not add a %union-dependencies declaration?  Its code could be
 > placed in the shared dependencies.  The pre-prologue and
 > post-prologue could sit outside but in the usual sequence.  This
 > should be backward-compatible, easier to understand, and compatible
 > with yacc.

I fear the introduction of zillions of %directives.  And in this
precise case, a %directive followed by code, I would first like to
split the handling of {} in a second scanner.