Re: prologue alternatives

[Paul Eggert]

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

> Even for yacc.c and glr.c, (1) the default 
> YYLTYPE is often quite satisfactory.

Well, the line number should be at least as wide as off_t (which `int'
typically isn't).  Similarly, the column number should be at least as
wide as size_t (if lines are buffered in memory) or off_t (if they
aren't).  Shoehorning these into 'int' is asking for trouble, unless
the location accumulator does overflow checking, which most don't.

However, if you say YYLTYPE works for you, perhaps I'm being too picky
about it.  Still, it's not that much intellectual effort to
cut-n-paste it if dependencies are a problem.

> 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 don't follow the second ("more importantly") point.  Distinguishing
between %stype-code and %ltype-code means we'll have to educate the
user about these problems anyway.  This extra education complicates
things just as much (if not more so) as saying "If you want YYSTYPE to
depend on YYLTYPE you'll have to define both".

As a sometime user of Bison (and as someone who inflicts it on
students :-) I don't want to have to explain a lot of twisty
directives that are all slightly different.  I want just one
directive.  Even if it's not perfect, it's often better than lots of
little directives that I can't keep straight in my head.

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

The user can define a header foo.h that looks like this:

  #include "y.tab.h"
  [now, declare header definitions that depend on y.tab.h]

and the user can then include foo.h instead of y.tab.h.
So a new directive isn't needed to address this issue.