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.

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.  We could choose one and promote it in the 
documentation... or even disallow the other in the case of Java.

Unfortunately, this now suggests that the term "header" might not be 
general enough.  It's fine with me to find a different word.  We could use 
%before-prologue, %start-prologue, %end-prologue, and %after-prologue. 
This implies that, in the case of C/C++, the prologue = the header.  I'm 
not sure that's our current terminology, but it's probably fine.

> BTW, I dislike %definition as opposed to
> %declaration, because
> 
>           extern int foo; // is a declaration
>           int foo;        // is a definition
> 
> and we mean declarations here.

I think it's a combination of variable declarations and struct/enum/class 
definitions... unless you call this:

  union YYSTYPE {
    int val;
  };

a declaration, and I think some people do.  I went with "definitions" for 
consistency with %defines.

Paul may have saved us from this particular debate by proposing 
%start-header and %end-header to replace %before-definitions and 
%after-definitions.  However, if we need to abandon the term "header" for 
the sake of languages like Java, maybe we need to consider these words 
again.

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

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

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

> - We use the header in the generated parser.

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

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

Joel