Re: glr.c: Token definitions

[Joel E. Denny]

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.

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

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

Joel