Re: prologue alternatives

[Paul Eggert]

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

>> But why bother to distinguish %stype-code
>> from %ltype-code?  Can't we simplify things even further by having
>> %type-code { ... } that carries both sets of code?
>
> Akim and I have observed that the semantic type may depend on the location 
> type.  However, we agreed that the reverse dependency seems quite 
> unlikely.  (Akim, please correct me if I'm misrepresenting you.)  Thus, 
> Bison should generate the location type definition before the semantic 
> type definition.

By "location type" do you mean the existing scheme where either the
user specifies a type or Bison supplies the default

   typedef struct YYLTYPE
   {
     int first_line;
     int first_column;
     int last_line;
     int last_column;
   } YYLTYPE;

declaration?  Or are you thinking of something fancier?

If the former, then I don't think we need to worry about the problem.
The default YYLTYPE is naive and is typically wrong.  Anybody who's
seriously using the sophsticated features we're talking about here,
will be defining their own location type anyway.  So they can handle
the dependency problem themselves, in a single bit of code that
defines both types.

So, to answer the question:

> What if the user defines the semantic type himself without using %union?  
> That is, what if he puts it in %stype-code?

Such a user should also define the location type.  So we don't need to
distinguish between %xtype-code and %ytype-code.


>> Come to think of it, why bother to distinguish %type-code from
>> %header?  Wouldn't %header suffice?

> %*type-code cannot depend on all the Bison-generated definitions.  
> %header can.

If you agree with the above discussion that users of this feature will
be sophisticated and will want to define their own location and
semantic types, then what Bison-definitions are we talking about here?
The token numbers?  Surely it's OK to output the token numbers before
outputting the contents of %header-code, since the token numbers can't
depend on what's in %header-code.

> (I'm wondering if %header ought to be called %header-code so that we can 
> talk about the %*code directives.)

Sounds good to me.  But I'd prefer just one %*code directive for the
header, to simplify things for the user.