push parser implemenation

[Bob Rossi]

Hi,

I've spent some time recently working on the push parser implementation.
I'd like to share my current patch, which passes the test suite and
works on my particular grammar as a push parser.

I'd like to get some feed back, to make sure I'm moving things in the
correct direction. I'd say at this point, I'm mostly done with the core
changes that need to take place. However, I'd suspect that a lot of
cleanup is in order.

I'll quickly discuss the patch here. 

1. %push-parser

The first part of the patch was adding the %push-parser option. 
I followed the way %pure-parser was implemented to get this to work.

2. struct yypvars and yypvarsinit

The next thing I did was add the struct yypvars. This contains all
of the local variables declared in yyparse. I also added the function
yypvarsinit which inits the variables in the struct. It is important 
to recognize that the struct is always used now, if you are using
the default parser, the pure parser or the push parser. In the case
of the default and pure parser, the struct yypvars is initialized
and destroyed at the r and end of yyparse. In the case of
the push parser, the user has to take that responsibility. I'm not sure
if this extra pointer dereference is inefficient.

3. yychar, yylval, yynerrs, and yylloc (external parser variables)

These variables remain external in the default parser. However, in
the pure and push parser they go in the struct yypvars.

4. Unfinished tasks

The user has no visibility into the struct yypvars. I added 2 accessor
functions for the user. 'int get_yyresult' and 'set_yychar'. However,
I'm assuming they need access to all 4 external parser variables, which
would mean I would need 8 accessor functions. Can you think of a better
way to solve this problem? Odd originally implemented this so that there
were 2 structs (yypvars and yyuvars). I thought the second struct added
confusion to the user side of things. It's nice to have 1 struct per
instance of the parser I think. Any advice?

Also, I have limited experience with bison. I would like to know what
the possible code generation possibilities are. For instance, can the
function 'output_skeleton' output m4 code that will have 'yychar' in it,
instead of 'pv->yychar'? What are the other possibilities?

I don't know if I am getting ahead of myself, but what would be the
appropriate changes to make to the test suite to verify that all of this
works?

Any other suggestions?

Thanks,
Bob Rossi

push.diff
Description: Text document