Re: glr: include the created header

[Akim Demaille]

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.  Bison can try
to implement these ideas, and the target language is not really
relevant IMHO.

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. 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.

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.

I understand that compatibility with Yacc is an issue, but
let's keep the bad things installed only when %yacc.

In my humble opinion, the relation between %{...%} and %union was Yacc- and C-based, and it was a bad thing. It was a bad thing not because it

was Yacc- and C-based but because it was limited and was dependent on
declaration order.  I fear I may have missed your point though.

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: order matters, just as is the most common
case.  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!

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.

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.

The fact that people use #define YYSTYPE is something which should
fight rather than encourage.  Why don't we simply complement %union
with %struct and %typedef (I don't like the name of the latter, it is
too C oriented

Isn't %struct also C oriented?  Do you intend that this addresses the
header issue?  I'm not seeing the connection.

Someone referred to the fact that we can't "feel" a direct definition
of YYSTYPE to separate the pre- and post-prologue.  So I suggest to
carry on the error of Johnson to the perfection and introduce %typedef
to let users specify the name of YYSTYPE.  But of course this is
just pushing the problem further...

I propose that

- we don't keep two %declaration keywords, that's only an implementation

  detail.
- Having a keyword to clarify that we are exporting declarations is
  nice, but let's keep it unsplit, and keep %{ %} as a synonym.
  Something like %declare, or %declaration, or %export.

Please see this discussion:

http://lists.gnu.org/archive/html/bison-patches/2006-06/ msg00107.html

Paul and I claimed that order-dependent declarations are problematic.

That is, in the grammar file, the position of these declarations relative

to %union shouldn't matter.

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.

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.

%private seems language agnostic enough, but I don't really care
about the name.

- We use the header in the generated parser.

I think it wouldn't be tough to make this happen in yacc.c now.

I don't remember the details, it might be hard indeed, but worth
striving for.  And if we cannot do that, we still must factor
the current code duplication in yacc.c using m4.

- We introduce a keyword that means that they are local to the parser file,

  maybe %private.  It is pasted after the inclusion of 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.