Re: prologue alternatives

[Joel E. Denny]

On Sat, 16 Sep 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > That isn't equivalent yet because yours doesn't place those "header 
> > definitions that depend on y.tab.h" in the Bison-generated code file.
> 
> It shouldn't be hard to come up with something that's equivalent,
> without departing from the traditional "yacc -d" model.  Let me try to
> derive it from my understanding of yacc -d.  It works by translating
> this:
> 
>     %{ A %}
>     %union { B }
>     %{ C %}
>     %%
>     D
>     %%
>     E

Let's say A defines YYLTYPE.  Let's say I reorganize my grammar and move 
or remove B.  Now suddenly the compiler complains that I'm redefining 
YYLTYPE.  That makes no sense.  What does %union have to do with YYLTYPE?

Let's say I have multiple B's:

  %{ #include "type1.h" %}
  %union { type1 field1; }
  %destructor { type1_destroy ($$); } <field1>
  %printer { type1_print (yyoutput, $$); } <field1>

  %{ #include "type2.h" %}
  %union { type2 field2; }
  %destructor { type2_destroy ($$); } <field2>
  %printer { type2_print (yyoutput, $$); } <field2>

The above code does not compile.  How many undergraduates know why?

> to this:
> 
>     A
>     [copy of y.tab.h]
>     C
>     [translation of grammar D into a parser]
>     E
> 
> where y.tab.h is derived from all the input (including (D)) and
> defines YYSTYPE and YYLTYPE if they're not defined already.
> 
> Given this model, users that don't know about %start-header can simply

If they don't know about or like %start-header (or %type-code as we've 
started calling it), they can use %{...%}.  I'm not suggesting we break 
Yacc-conformance by removing it.

> prepend "#include <parser.h>" to (C), where parser.h looks like this:
> 
>       #include "y.tab.h"
>       [other definitions]
>
> Other source-code modules simply #include <parser.h>.
>
> y.tab.h is idempotent; it doesn't hurt to include it if it (or a copy
> of it) is already included, so other modules can simply include
> parser.h.  

Users that don't want to think through these arcane declaration order 
issues, %union and %{...%} interactions, and tedious #include solutions 
can simply think about this:

  1. Type code goes in %type-code {...}
  2. Other header code goes in %header-code {...}
  3. Other code goes in %code {...}

That is, the user tells Bison what each piece of code is for, and Bison 
handles the gory details.

> This mechanism is fairly simple

I've used it, and I disagree.  Bison should do the work.  Not me.

>, and it doesn't require the
> %start-header/%end-header business that I am having so much trouble
> following.

Does calling them %type-code/%header-code help?  %type-code is like A and 
%code is like C... both regardless of whether there's a B.  %header-code 
is a new feature.  Ignore it if you like.