Re: prologue alternatives

[Joel E. Denny]

On Thu, 14 Sep 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > On Wed, 13 Sep 2006, Paul Eggert wrote:
> >
> >> The
> >> old way is messy and complicated, but at least it's standardized and
> >> has well-known properties.
> >
> > Do these well-known properties include the way Bison puts %{...%} 
> > sometimes in the header?
> 
> No, sorry, I was referring only to the yacc method.

Ok, good.  I was a little worried users may have become dependent on this.  
Unless I've missed something, I believe we're all in agreement that we 
should leave out this feature.

> That's simpler, thanks.  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.

What if the user defines the semantic type himself without using %union?  
That is, what if he puts it in %stype-code?  Bison will need to generate 
%stype-code after the location type definition but generate %ltype-code 
before:

  -------------------------------
  enum yytokentype
  %ltype-code blocks
  YYLTYPE definition
  %stype-code blocks
  YYSTYPE definition
  %header blocks
  -------------------------------
  %code blocks

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

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