Re: glr: include the created header

[Joel E. Denny]

On Wed, 28 Jun 2006, Akim Demaille wrote:

> What if you use an extra field in your YYSTYPE that needs the YYLTYPE?

My solution has been to define YYLTYPE myself (exactly with the fields 
Bison advertises) so I can choose the order.  If Bison were to put YYLTYPE 
before YYSTYPE, I wouldn't have to do that, but I haven't yet discussed 
that enhancement.  I see no reason to accommodate the reverse case of a 
YYSTYPE in a YYLTYPE.

> My point is that it is precisely the before/begin/end/after syntax
> that does not scale.  The user should continue to write her prologue
> as if it were a single chunk, it just happens that, due to syntactic
> choices, she has to "escape" from it momentarily to define YYSTYPE.

For some bizarre reason Bison subtly decides this is the same moment to 
define YYLTYPE and the enum.  That makes no sense to me.  Regardless, if I 
want to block the typdedef for YYLTYPE, I have to know this.  If I want to 
use the Bison-generated YYLTYPE in one of my own function declarations, I 
have to know this.  If there is no %union, I don't know what to do for 
sure anymore.  If I want to define YYSTYPE myself, I don't know what to do 
for sure.  We're not hiding the messy implementation details from the 
user.  We can't.  He has to know where the code will be placed.  Let's 
make it explicit instead of having a subtle %union dependency.

>  > I figured it was better just to stop guessing at what the user
>  > wants and let him declare it explicitly.
> 
> Very much agreed.  That "explicit" is precisely the order in which she
> declares her stuff.

One implicit subtle part is understanding that somehow %union has anything 
to do with YYLTYPE and the enum.  When the user doesn't declare %union, he 
loses the ability to declare either before or after the YYLTYPE and enum.  
(Which is it again?)  That makes no sense!  I was trying to eliminate such 
subtleties by making it explicit.

>  >   %semantic-type {
>  >     #include "type1.h"
>  >     #include "type2.h"
>  >     union YYSTYPE {
>  >       type1 field1;
>  >       type2 field2;
>  >     };
>  >   }

I've edited the above to reflect my earlier corrections.

> This is going to be virtually impossible for bison to parse this.

Why does Bison need to parse it anymore than Bison needs to parse %{...%}?

>  > That eliminates the subtle order dependence that bugged me.
> 
> I don't think this is what bugged you: as far as I remember, what was
> truly utterly annoying is the policy that decides whether it is to be
> exported or not.

It's all interconnected.  Sorry if I haven't explained it well.  There's 
some old fable about blind people and an elephant that's relevant here.  

>  > I'll be more specific: I don't like that the grammar file position
>  > of the %union is important and that this importance is revealed to
>  > the user in subtle and ugly ways.
> 
> Again, I disagree.  *Of course the order matters*!  This is C.  Not a
> single C programmer can expect
> 
> foo bar;
> typedef int foo;
> 
> to work.  That's the same here.  We're uselessly (IMHO) breaking the
> connection with the host language.

Not a single C programmer would expect that this:

  /* pre-prologue */
  #include "type1.h"

  /* %union */
  union YYSTYPE {
    type1 field1;
  };

  /* post-prologue */
  typedef struct YYLTYPE {
    int first_line;
    int first_column;
    int last_line;
    int last_column;
    char *filename;
  } YYLTYPE;

would complain that YYLTYPE is redefined unless they knew the messy 
details of Bison.  You have to move the YYLTYPE stuff before the union.  
That makes no sense.

>  > Yet somehow we seem to be trying to hide the concept of the pre-
>  > and post-prologues.  It's not working.
> 
> Why and where?  Currently I do not see it is not working. In
> particular, this is not what is implemented currently, nor has it ever
> been implemented in Bison.

I thought you've been arguing that pre-prologues and post-prologues are 
implementation details that should been hidden from the user.  I see those 
details often as a user.  One example is above.

>  >> The difference between before and after is then irrelevant!
> 
>  > It's relevant if you're writing a struct definition that requires
>  > YYLTYPE or the enum.  You want it to be after.
> 
> Exactly!  That's my point!

I'm lost.

> The syntax must not require the user to
> follow our 2^n directives to match her case.

What is n?  I think it's 2.  That's it.

> She should continue to
> declare as usually, and let *us* deal with the mess underneath.

I'd like that.  The %union-dependent approach exposes the mess in subtle 
ways (one example is above).  The %*-header approach at least makes the 
mess explicit.  Another solution may be to have %semantic-type and 
%location-type and have Bison generate the location type before the 
semantic type.

>  > If you're writing code that typedef's YYSTYPE, then you have to
>  > #define YYSTYPE YYSTYPE before in order to prevent the
>  > Bison-generated typedef.  My point here is only that there are many
>  > cases to consider and document.  It's messy.
> 
> Again, that's my point.

There are so many cases to consider and document for the %union approach.  
There are exactly 4 for the %*-header approach.  That's my point.  Maybe 
%semantic-type and %location-type are better.

>  > For consistency with Yacc, I'd say %private would be the alias for
>  > %{...%}.  If we have to have something like %{...%} for the header,
>  > I think it should not be a Yacc construct or we have confusing
>  > inconsistency again.
> 
> Because %union is exported, because in the tradition of Yacc the
> prologue is also used to define the requirements of %union, it seems
> more logical to me to consider it is actually %public.

And then we're back to the inconsistent approach of Bison 2.3.  %{...%} 
doesn't go in the header for Yacc.  Now, if you're saying it can even for 
yacc.c, then it's something to consider.  If not, why can't we just leave 
%{...%} alone and create something that's not Yacc?

> I've not sort out the details yet, that way ahead, but I'm thinking
> about something like
> 
>     return yy_symbol (token-type, token-value, token-location);

What is token-type?

Joel