Re: push parser

[Joel E. Denny]

On Tue, 5 Dec 2006, Bob Rossi wrote:

> Actually, currently, the user can not access the fields at all. That's
> what I'm trying to say. The user can not index into the struct, because
> the struct is only forward declared in the users translation unit. I
> think it's good to not allow the user access to this structure. However,
> if it's desired and thought wise, it can be done.

Ah, I get it now, thanks.  I was thinking of code in the same translation 
unit.  For example, imagine the user who writes his main routine in the 
epilogue.

I'm usually not too concerned about supporting users who mess around in 
undocumented parser internals.  However, there's another advantage with 
your approach: if we have a yypstate_new, users will be forced to think 
about memory management, and so they'll hopefully be encouraged to think 
about invoking a yypstate_delete.  For now, yypstate_delete would simply 
call free, but one day (or in some other skeleton) it may need to do more.  
In other words, we can evolve without breaking legitimate user code.

By the way, why does yypvarsinit return a void* instead of a struct 
yypvars*?

Also, I think Bison should generate:

  typedef struct yypvars yypvars;

similar to YYSTYPE and YYLTYPE.

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

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.

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

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.

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.

By the way, I just noticed there's something wrong with the m4 in the 
header file.  You don't generate YYPUSH_MORE and yypvars declarations 
unless locations are turned on.

> > > > 7. Shouldn't you remove the yyparse prototype you're currently 
> > > > generating 
> > > > in push mode?
> > > 
> > > The patch I'd like removed completly removes the yyparse function in
> > > push mode. Are you asking about something else?
> > 
> > No, it leaves the prototype and a #define.  Search the patched push.c for 
> > yyparse.  The first three occurrences need to be addressed.
> 
> I see, you'd like all occurences of yyparse to be completly removed in 
> push-parser mode, if we don't add #8. Yes, that makes complete sense.

Actually, especially if we do add #8 since yyparse would be a #define 
then.