[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: glr.c: Token definitions
From: |
Joel E. Denny |
Subject: |
Re: glr.c: Token definitions |
Date: |
Wed, 21 Sep 2005 12:06:21 -0400 (EDT) |
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
- Re: glr.c: Token definitions, (continued)
- Re: glr.c: Token definitions, Paul Eggert, 2005/09/19
- Re: glr.c: Token definitions, Joel E. Denny, 2005/09/19
- Re: glr.c: Token definitions, Paul Eggert, 2005/09/20
- Re: glr.c: Token definitions, Akim Demaille, 2005/09/21
- Re: glr.c: Token definitions, Joel E. Denny, 2005/09/21
- Re: glr.c: Token definitions, Akim Demaille, 2005/09/21
- Re: glr.c: Token definitions, Paul Eggert, 2005/09/21
- Re: glr.c: Token definitions, Joel E. Denny, 2005/09/23
- Re: glr.c: Token definitions, Joel E. Denny, 2005/09/23
- Re: glr.c: Token definitions,
Joel E. Denny <=
Re: glr.c: Token definitions, Akim Demaille, 2005/09/20