Re: push parser implemenation

[Akim Demaille]

>>> "Bob" == Bob Rossi <address@hidden> writes:

 >     Theoretically, a function in bison uses a local variable named
 >     "lfoo" and a global variable named "gfoo". I need to pack both
 >     of these into a struct, named "sfoo".

I agree the most probable loss is there: formerly register stored
variables are now in ram.  Some compilers are able to remove the cost
of this abstraction though.


 >> 1. I think you should not change the semantics of yyparse in the push
 >> parser.  In fact, I think the push parser should always provide
 >> yyparse as the good old pull interface wrapping the yyparse_push
 >> interface or whatever.
 >> 

 > OK, so you would like the push parser to have a yyparse () function that
 > internally calls yyparse_push? I can do that, even though I really don't
 > see the point. Why would a user want to use the push parser if they
 > didn't want to use it in push mode? There probably is some advantage to
 > this that I can't think of though.

I think that keeping a common interface is a very important feature.
I'm very happy I can switch from yacc.c to glr.c or from lalr1.cc to
glr.cc straightforwardly.  That eases the migration from one set up to
another.  And it also considerably eases our maintenance tasks: same
tests suite and same bench suite.

 > Would you like me to name it yyparse_push? or yyparse_wrapper?

*wrapper is way too generic a name, push is ok.


 > There are currently 4 user visible variables. They are
 > yychar, yylval, yynerrs, and yylloc.

 > I am proposing 4 set's of set/get functions that give the user access to
 > these variables. If that is acceptable, I'll add the functions into the
 > patch.

Yes, I think this is a best approach.


 >> 3. I don't think we should maintain the Cartesian product of all the
 >> badly designed features, so I suggest that push => pure.  There are
 >> a couple of place where the (m4) code could be simplified then.

 > Are you saying you don't want to see %push-parser option, but rather 
 > change %pure-parser to be the new "push parser"?

No, I'm suggesting that push.c should not support non pure parsers,
i.e., if the user asked for push, then pure comes as an additional
feature.


 >> 4. Also, YYPARSE_PARAM is bad, does not scale well, etc.  Don't bother
 >> with it except to maintain compatibility with the old mode.

 > OK, so just take those cases out?

Yes.  It is hard to extend to the other skeletons etc.  That's an old
feature that plain yacc.c should be the only one to have to deal with.