Re: push parser

[Bob Rossi]

On Wed, Dec 06, 2006 at 03:11:04AM -0500, Joel E. Denny wrote:
> > > > > 4. If %push-parser implies %pure-parser, why not code that logic into 
> > > > > parse-gram.y?  That is:
> > > > > 
> > > > >   | "%pure-parser"      { pure_parser = true; }
> > > > >   | "%push-parser"      { push_parser = true; pure_parser = true; }
> 
> > I see. Well, they don't make sense to put together. However, the
> > push-parser and the pure-parser are still very different in the yacc
> > skeleton. Sorry if I'm explaining this, and you already know, but at
> > least we will be on the same page. The original yacc skeleton has
> > several variables in the function yyparse, and 4 variables that are
> > global.  The pure-parser has all the variables declared in the function
> > yyparse. The push-parser declares a lot of the variables in a structure, 
> > which is passed in and out of yyparse. My point in saying this is to say
> > that there is no real correlation between push-parser and pure-parser.
> > In fact, if the user sets both options, it should be an error.
> 
> I notice you keep saying *the* pure parser rather than *a* pure parser.  
> I think this is the discrepancy between our views.  In my view, 
> %pure-parser is not a separate kind of parser.  Instead, it's one of many 
> variables defining the parser output by Bison.  In theory, it should be 
> possible to have any of the following combinations:
> 
>   impure LALR(1) pull C
>   pure   LALR(1) pull C
>   impure GLR     pull C
>   pure   GLR     pull C
>   impure LALR(1) push C
>   pure   LALR(1) push C
>   impure GLR     push C
>   pure   GLR     push C
>   (Now repeat the list for C++.)

Hmm, I'm not sure this is true. There is no impure push parser. It's not
possible. Please correct me if I am wrong.

> However, you have chosen to eliminate the possibility of combining impure 
> with push.  In this view, declaring %pure-parser should be considered 
> required or redundant but not erroneous.  As I recall, Akim argued for the 
> same view because that's the view he took when he decided C++ parsers 
> should never be impure.

I think if you pick the %pure-parser option along with the %push-parser
option it should be an error. It doesn't make sense. The pure parser
wants to declare variables inside the yyparse function. The push parser
wants to declare variables inside the 'struct yypstate' object. There
are other differences as well.

> Now, back to the skeleton where all this matters.  Assume your view that a 
> pure parser and a push parser are two separate kinds of parsers.  I see 2 
> existing places where a b4_pure_or_push_if could abbreviate your code 
> (both have something to do with b4_declare_parser_variables).  Since the 
> precedent is to have yyerror take a location any time it won't break 
> backward-compatibility, you'll also need something like b4_pure_or_push_if 
> in b4_yyerror_args as you suggested here:
> 
>   http://lists.gnu.org/archive/html/bison-patches/2006-10/msg00058.html

Yes, there is some commonality between the push and pure parser. There
are also some differences. For instance, with the example above, if the
user selects push-parser, and we auto set pure-parser, then push.c is
going to want to declare variables in both yypush-parser and inside the
'struct yypstate'. So, either there will be redundent code, or I'll have
to somehow write a macro that detects if the user really wanted
push-parser or not, event though the option is true.

> If we're going to have a yypull_parse, there are checks for purity in 
> computing the yylex prototype that would also need to be changed to check 
> b4_pure_or_push_if.  Finally, I see that your header file is generated 
> with externs for yylval and yylloc, which shouldn't happen since push 
> parsers are pure.  For glr.c, it looks like all this is going to get even 
> worse.

Yes, this is still a problem. There are several things like this that
are left around, that need to be cleaned up.

> Now consider my approach where %push-parser implies %pure-parser.  All 
> those previous places would only need to check b4_pure_if (as most already 
> do) because all they really are concerned with is purity.  I see no place 
> that you would need a b4_pure_but_not_push_if.

I've given at least one example above, I could attempt to come up with
others if you would like.


With all of this said. I'm not in a position to debate what is right or
wrong with regards to standard bison development decisions. I obviously
don't agree that what you are suggesting should be done. However, if you
insist you are correct, I'll do the work. I appreciate all the help that
you have provided me so far.

Paul, maybe you could way in on this too?

Thanks,
Bob Rossi