Re: prologue alternatives

[Paul Eggert]

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

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

It's easy to see why it doesn't compile, once you look at the
generated C code, and it's easy to fix once you see the problem.

YYSTYPE's implementation as a single union is inherent to this
problem; it's what's driving a lot of the issues here.  If we stick to
that implementation, there will be silly limitations (silly, from the
point of the grammar, anyway) no matter how we gussy things up in
Bison input.

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

That's a good principle, but I want it to be simpler if possible.
It's simpler if we have just two categories: header code, and
non-header code.  Users can easily see why we need to have these two
categories, because they understand the difference between
header/interface and code/implementation.  It's not so easy to see why
Bison needs _three_ categories.

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

How about if we have two categories: %{ ... %}, which puts the code
into the implementation, and %header-code{ ... }, which puts it into
the interface?  Plus, we have special strings $declare{YYSTYPE} and
$declare{YYLTYPE} that can be put in the "..." part of the directives,
and which expand to declarations for YYSTYPE and YYLTYPE, so that the
user can specify exactly where the Bison-generated declarations go.
Code would generated in the order the user specifies.

This is a lower-level mechanism than what you're proposing, but it
specifies the problem space clearly and it gives the expert user
finer-grained control over where things go.