Re: glr: include the created header

[Akim Demaille]

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

 > Ok, I think I'm beginning to see what you're meaning.  Sorry for my
 > previous misunderstandings.

I'm certainly more guilty of misexplaining than you are of
misunderstanding :)


 >> In this case the user can simply put things before and things after
 >> the %union.  What if some day we add a means to define some other
 >> type, say %location-struct {...} defining YYLTYPE.  Would we want
 >> to also have different pre and post primitive to order them, and
 >> users should choose which to use?

 > If the order was originally dependent on %union, it's unclear to me
 > what should happen.  If the order was originally declared by
 > %*-header declarations, I don't see the need for any additional
 > declarations just because we add %location-struct.

What if you use an extra field in your YYSTYPE that needs the YYLTYPE?
The day Johnson open this can of worms, by putting the definition of
the %union on Yacc's shoulders instead of the user's, we created a
situation where we should have to face all the possible orders.

 > This is exactly why I don't like order dependence among the Bison
 > declarations.  It doesn't scale.

I disagree, it scales just as well as if it was a continuous prologue
with an embedded definition of YYLTYPE and YYSTYPE in it.  Of course
it gets more complex for Bison that must keep track of what the user's
order was.

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.


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


 > Moreover, not all languages have unions, so pushing the semantic
 > type definition completely into the target language eliminates the
 > need for a new semantic type declaration for each new language.

That's another reason why I don't like %union at all, it breaks some
abstraction.  The fields should be exclusively under the
responsibility of the tool (granted, yylex is another matter, and it
does simplify to have tags here.  But it is not mandated, yylex has
the token type).


 > I suppose we could drop the %*-header declarations and we could add
 > a %semantic-type (and maybe one day a %location-type) that contains
 > literal code in the target language.  In it, the user would write a
 > consolidated definition of the semantic type plus dependencies:

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

This is going to be virtually impossible for bison to parse this.  I
don't think we need this anyway, %public and %private address this
issue too, in addition to letting the user declare things that are not
to be considered as related to the %semantic-type.


 > 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.  That's %private and %public, and it's unrelated to
where %union appears.


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

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



 >>> That's different than an unlimited number of prologue
 >>> declarations spread throughout the declarations section such
 >>> that, for each one, you have to hunt to find out whether it's
 >>> before or after the %union.  And if there is no %union, then what
 >>> happens?
 >>
 >> 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!  The syntax must not require the user to
follow our 2^n directives to match her case.  She should continue to
declare as usually, and let *us* deal with the mess underneath.

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



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


 >> >   %start-header { #include "type1.h" }
 >> >   %union { type1 field1; }
 >> >   %destructor { free1 ($$); } <type1>
 >> >   %printer { print1 ($$); } <type1>
 >> >   %type <type1> a b c
 >> >
 >> >   %start-header { #include "type2.h" }
 >> >   %union { type2 field2; }
 >> >   %destructor { free2 ($$); } <type1>
 >> >   %printer { free2 ($$); } <type1>
 >> >   %type <type2> d e f

 > Hmm... so many typos.

 >> Your code demonstrates exactly my point: the order matters, and so
 >> much to your eyes that you would never have put the %start-header
 >> after the %union.

 > I agree completely.  However, you can see why %{...%} would not work in
 > place of %start-header above.  The second %{...%} would be placed after
 > the %union.

Because currently Bison is not meant to cope with this.  That doesn't
mean we cannot spare the user 2^n additional directives.


 > The scanner needs to know the name of the union field... unless
 > you're restricting this to some future scannerless mode.

Scannerless, quite another adventure :)

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


 > Are you going to require a one-to-one correspondence between
 > modules and fields?

Certainly not!  I was just taking your structure into account.
The boundaries are most probably by natural subgrammars, say
expressions, statements, declarations for some cases, etc.