Re: glr.c: Token definitions

[Akim Demaille]

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

 > On Tue, 20 Sep 2005, Paul Eggert wrote:
 >> "Joel E. Denny" <address@hidden> writes:
 >> 
 >> > What if the #define's disappear for %pure-parser?
 >> 
 >> But whether to use #define is independent of whether the parser is pure.

 > I agree that it's a loose connection.  However, since people who want a
 > reentrant parser may often be the same people who desire a generally
 > clean/pure global namespace, it seems like removing #define's would be
 > another step they might appreciate.

 > I was trying to imitate bison's model for deciding whether to pass
 > locations to yyerror() for LALR(1) parsers.  That is, bison passes
 > locations for some combination of options for which a new yyerror()
 > interface shouldn't be a backward compatibility issue.  Likewise, I was
 > assuming no user of %pure-parser would find the removal of #define's to be
 > a compatibility issue.

 > While I feel there is a logical connection between no #define's and
 > %pure-parser, I don't see a logical connection between a yyerror()
 > location param and an `absolutely pure parser'. In this case, a
 > declaration like %yyerror-locations would have been more flexible.  I'm
 > supposed to lecture next week on how to set up location tracking using
 > flex and bison, and I don't look forward to explaining the seemingly
 > unrelated chore of setting up an absolutely pure parser.

I have the same problem when I lecture this too, but it is not as bad
as you report because it makes very little sense to have a
%pure-parser without a %parse-param.  So basically, if you skip the
weird %pure-parser and no %parse-param state, the dirty bits are not
visible.

Personally I dislike the explosion of the number of directives.  It's
wrong for the user.

 >> Instead, how about if we make the #define's disappear when the --yacc
 >> (-y) option is not used?

 > I actually like that even better.  I thought about it but didn't suggest
 > it after reading this in the manual:

 >   The purpose of this option is to imitate Yacc's output file name
 >   conventions.

 > However, if the spirit of `--yacc' is simply to make bison yacc compatible
 > as the name suggests, then it makes sense to me.

That's good with me too.  I'd be very happy to get rid of the
%pure-parser/%parse-param combination to simply using %yacc or not %yacc.

 > Again, perhaps the yyerror() location parameter should be added by a
 > clearly connected declaration rather than as a side-effect of seemingly
 > unrelated declarations.

Using %locations should simply propagate the location to everybody.
Bugward compatibility prevented this :(


There's something else that might simplify everything: how about
having something like:

%error-report {
  location_print (stderr, @$);
  fprintf (stderr, "%s\n", $$);
  ++errs;
}

i.e., freeing the user from having the prototype yyerror?