Re: glr: include the created header

[Akim Demaille]

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

Hi Joel,

Sorry for the lag,

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

I agree, but I don't know.  My point was that in the end we are only
talking about the order into which things are emitted.  And there can
be many possible combinations in the future if we feel the need for
something like a %location {...} etc.  So we should not have to rely
on explicit directive names to specify that order: let the order
itself be the specification of the order into which things are to be
emitted.


 > For some bizarre reason Bison subtly decides this is the same
 > moment to define YYLTYPE and the enum.  That makes no sense to me.

Well, it did because currently we have a single means that deals with
two different matters:
- order
  typically include the dependencies first, then add the complement of
  definitions (e.g., the prototype of yyerror) after the definition
  of the generated types.
- visibility
  i.e., goes into the .c or .h.

That mandated where the enum and YYLTYPE had to be defined.

 > Regardless, if I want to block the typdedef for YYLTYPE, I have to
 > know this.

That's because Bison doesn't know this either.  It is dead wrong to
continue to rely on #defines to define this kind of stuff.  With
genuine directives Bison will know enough to know where to put, or not
to put, YYLTYPE etc.

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

Again, I agree with that point.  But the problem here is not the need
for before/after/start/end, rather it the fact that sometimes we tell
bison (using %union), sometimes we don't (using #define).  _That_'s
the problem.


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

Agreed.  Let's introduce %typedef, and %location (or so).


 >> >   %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 %{...%}?

In your original proposal there was no YYSTYPE, and I though you meant
to have bison parse this to find the different parts.



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

Agreed.  But then again, the problem is %location.


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

We fail to communicate efficiently here :( pre- and post- prologues
_are_ implementation details, and *yes* the current set up makes it
visible to the user.  But to cure the situation requires to fix the
incorrect way things are issuing rather that pushing the complexity on
the user who will have to learn more directives instead of just
repeatedly use the same, but in a specific order.



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

We're converging :)


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

I don't see that.

 > %{...%} doesn't go in the header for Yacc. 

That stinks, and that's what I propose to change.  If backward
compatibility is your problem, remember that we have %require that
makes it very easy for us to implement both schemes.

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

Because I don't see the point of not making the simple thing work!


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

The int value returned by yylex, the kind of token that was returned
(BRACED_CODE, INT, etc.).