Re: prologue alternatives

[Joel E. Denny]

On Fri, 15 Sep 2006, Paul Eggert wrote:

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

I'm also thinking of location.cc, but the issues seem nearly the same.

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

Maybe I'm an atypical user.  Even for yacc.c and glr.c, (1) the default 
YYLTYPE is often quite satisfactory.  At the same time, (2) I often do 
still need to define YYSTYPE dependencies, and (3) I do want YYSTYPE to 
depend on YYLTYPE.

For example, I may build a parse tree from one file at a time, so (1) I 
don't need a filename field in YYLTYPE.  However, (3) I do want to put 
location information in my parse tree, and YYSTYPE contains my node types, 
which (2) are defined in external files.

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

Your combined %type-code seems to be just a rename of what we now call 
%start-header.  As I recall, the separation into %stype-code and 
%ltype-code came about so that the user wouldn't have to copy and paste 
the default YYLTYPE definition and, more importantly, know to do so.  I 
was trying to find ways to keep the user from having to think about 
low-level declaration order issues: at first it's not obvious that 
defining a YYSTYPE that depends on YYLTYPE somehow means that the user 
can't depend on Bison to define YYLTYPE.  However, understanding that you 
should put all YYLTYPE code in %ltype-code and all YYSTYPE code in 
%stype-code seems easy.

Having said all that, I personally don't mind copying and pasting Bison's 
YYLTYPE definition.  %start-header works for me.

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

But shouldn't we also handle the case where the user doesn't want to 
override YYSTYPE (generated from %union perhaps) or YYLTYPE but does want 
to add header definitions that depend on them?  I think we need a separate 
directive for this: %end-header (current way) or %header-code (proposed 
way).

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

Also, for lalr1.cc, there's yy::parser.  The user may like to add header 
definitions that depend on it.