Re: push parser

[Joel E. Denny]

Well, I found a little time much earlier than I thought....

I haven't been following the push parser development closely, so I decided 
to browse this thread a little to catch up.  I'll read the latest patch in 
detail later, but I have a few initial questions and comments:

1. How was the name yypvars chosen?  What does ctx stand for?  Context?  
It seems we have about three terms for the same thing: parser state, vars, 
and context.  This will make the documentation a little confusing I fear.  
I think we should pick one term and stick with it.  I prefer parser state, 
which implies renaming yypvars to something like yypstate.

2. I find it strange that yypvarsinit invokes malloc.  That would be 
something more like yypvarsnew, in my opinion.  Also, the user may wish to 
use automatic storage.  I think the following makes more sense:

  struct yypvars ctx;
  yypvarsinit (&ctx);

3. How about an underscore between words for readability?  Combining #1, 
#2, and #3:

  struct yypstate state;
  int status;
  YYSTYPE my_lval;
  YYLTYPE my_lloc;

  yypstate_init (&state);
  do {
    status = yypush_parse (state, yylex (&my_lval, &my_lloc),
                           &my_lval, &my_lloc);
  } while (status == YYPUSH_MORE);

Notice that the word separation in yypush_parse is consistent with 
%push-parser.  The only other new underscore is in yypstate_init.

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; }

It appears as if you often have to check both b4_push_if and b4_pure_if 
when you should really only need to check b4_pure_if.  This should help.  
(In a similar manner, %glr-parser implies %nondeterministic-parser.  In 
that case, it's the front-end that's simplified rather than the back-end.)

5. For yyerror arguments, why not just stick with whatever pure parsers 
normally use?  #4 should help.

6. I read somewhere in this thread that yypushparse will never modify its 
yynchar, yynlval, and yynlloc arguments.  Shouldn't they be const then?

7. Shouldn't you remove the yyparse prototype you're currently generating 
in push mode?

8. Akim wanted there to be a yyparse for pull mode.  You and Paul have 
noticed that this would create a dependence on yylex even when the user 
isn't interested in pull mode.  Wouldn't making yyparse a C macro solve 
this?

  #define yyparse() yypull_parse (&yylex)

Then define yypull_parse as the function wrapping yypush_parse.  This way, 
yylex is never referenced unless the user invokes yyparse.

And if we're going to do that, I'd like for yypull_parse to accept a 
yypvars (or yypstate).  Then the user can combine yypush_parse and 
yypull_parse.  For example, the user can yypush_parse a token to select a 
sub-grammar and then yypull_parse the input stream.

Passing NULL for the yypvars could instruct yypull_parse to construct a 
yypvars internally, so then we'd have:

  #define yyparse() yypull_parse (NULL, &yylex)

This maintains the usual prototype of yyparse as Akim wanted.