Re: glr: include the created header

[Joel E. Denny]

On Tue, 27 Jun 2006, Akim Demaille wrote:

> > > I am not convinced this was the right move.  I feel there is too many
> > > possible choices here, driven by C's model where you split definitions
> > > and declarations.
> > 
> > Since Bison has at least two backend languages (C and C++) that use this
> > model, it seems we ought to accommodate the model.
> 
> This is not what I mean.  What I meant is that we can live without
> these arcane matters, other langages have proved it.

Other languages like Java?  How does that address C and C++ support?  
Again, I think I just don't know what you mean.

> > If Bison later grows Java backends, for example, the old Yacc-style
> > prologue blocks should be sufficient... unless the user doesn't like that
> > %union divides them.

Or rather, whatever the Java counterpart of %union would be.

> > That is, if he wants his declarations to be order
> > independent, he could choose either %start-header/%end-header or
> > %before-header/%after-header.  In the case of Java, I'm not sure it
> > matters which pair he chooses.
> 
> In modern languages, the order is irrelevant.

Sorry, thanks, I forgot.  So the Java user probably won't want either.  
In that case, the new %*-header declarations present no complexity to him 
since he can easily stick to %{...%}.  The %*-header declarations may only 
be useful for C/C++.  What's wrong with that?

> > > If we were programming in some other model than C or C++, we would not
> > > have all these sections, and I much preferred when we had that
> > > illusion.
> > 
> > I can't see how we can make a Bison grammar quite so agnostic of the
> > backend language.  We're talking about blocks of verbatim code here.
> > There's an inherent dependence on the backend language.
> 
> I agree, but let's not fall into this without trying to avoid it.

Ok, we could drop the new declarations and provide only prologue blocks 
that will insert code only into the code file (for consistency with Yacc).  
That will accommodate languages like Java, and the C/C++ user can write a 
file called parser.h that contains this:

  #include "pre-parser.tab.h"
  #include "parser.tab.h"
  #include "post-parser.tab.h"

where Bison generates parser.tab.h.  The user can then put this in his 
code file:

  %{
    #include "pre-parser.tab.h"
  %}
  %union { int val };
  %{
    #include "post-parser.tab.h"
  %}

This seems less readable to me.  But, without the new declarations, how 
else will the C/C++ user be able to avoid repeated code and yet have 
control over his header file?

> My point is that the very feature is order dependant, and I fail to
> understand the point of making the interface more complex instead of
> sticking to what we have:

What we had as of Bison 2.3 was limited and inconsistent among the 
skeletons.  I found that more complex because the inconsistencies were 
confusing and the limitations were ugly to work around.

If a user likes the Yacc-style prologues, he's free to use them.  If he 
needs finer control for C/C++, only then will he have to understand the 4 
%*-header declarations.  Once a user has recognized a need for finer 
control, do you think he'll find these declarations confusing or too 
complex?

> order matters, just as is the most common
> case.

Order matters in C/C++.  That doesn't mean we can't eliminate unnecessary 
order-dependence from Bison declarations.

> We already teach our dear users that they should prototype
> in the prologue the functions they use in the core grammar, but
> that are defined in the epilogue.  I have no plan to make this
> commutable.  This is C!

I wouldn't suggest that either.  But there's only one epilogue and it 
always has the same position in the grammar file.  That's different than 
an unlimited number of prologue declarations spread throughout the 
declarations section such that, for each one, you have to hunt to find out 
whether it's before or after the %union.  And if there is no %union, then 
what happens?

> The pre- and post-prologue are just implementation details.  Had
> Johnson made the (saner IMHO) decision to leave the definition of the
> union to the user, using regular union {...} etc., *within* %{ %},
> we would never have even thought about its having two parts.
> 
> Actually yystype could even be included directly in the prologue
> where %union appears.  This is no longer true since we can glue
> several %union together, because we added several other features,
> but that's not a reason to make the interface more complex.

Why was the ability to concatenate several %union's together added?  If 
the freedom of code organization that this allows is still appealing, then 
why is the following not appealing?:

  %start-header { #include "type1.h" }
  %union { type1 field1; }
  %destructor { free1 ($$); } <type1>
  %printer { print1 ($$); } <type1>
  %type <type1> a b c

  %start-header { #include "type2.h" }
  %union { type2 field2; }
  %destructor { free2 ($$); } <type1>
  %printer { free2 ($$); } <type1>
  %type <type2> d e f

> Now we're streching that to such an extend that we consider four parts!
> Fortunately we did not introduce %location-definition, the combinatorial
> explosion would have led to quite a linguistic challenge to name all
> these sections.

A user can #define YYLTYPE in a %start-header and use its definition as 
well as the enum in a %end-header or %after-header.  I see no explosion.  
All these Bison-generated declarations/definitions are grouped together 
between the %start-header and %end-header.

> I disagree with these arguments.  Maybe some day someone will come and
> tell us that to ease her generation of files, we should introduce more
> levels, sort of m4's diverions.  I'm not willing to complement the
> current interface with %part 2 {...} %part 1 {...} issue her code in
> the correct order.

I can't really debate that point since I can't imagine what those 
declarations would be for.

> Currently I am still not convinced we need something more than a
> means to keep information private to the generated *.c/*.cc files.
> The rest is just prologue, and it should go into the header, in
> the order in which it appears.

When there's no %union, where does the prologue go in the header?

> > I think it's convenient to have one for before the header as well.
> > Currently we call it %before-header.  Is there a better way to `#include
> > "system.h"' in the code file?  Yes, this is a C/C++ problem, but I think
> > it's nice to accommodate it, and it keeps the full symmetry of these
> > declarations.
> 
> But why don't you put it into the header file anyway?  Headers are
> expected to be self contained.  That's the current trend, and
> it's by far saner, safer, simpler.

I didn't know that was the current trend for system.h.  Maybe Bison should 
follow this trend internally as well?  If you were trying to move to this 
trend, I'm afraid I undid your work earlier this month.  Sorry.

Joel