Re: push parser implemenation

[Bob Rossi]

On Fri, Sep 08, 2006 at 04:48:27PM -0700, Paul Eggert wrote:
> Bob Rossi <address@hidden> writes:
> 
> > The only catch, is that I compiled with -02. If you compile with out
> > optimizations it seems to be 1-2% slower, don't know why that is.
> 
> That's OK.  Thanks.
> 
> > Actually, I thought the LALR(1) was the yacc skeleton, but apparently it
> > is its own skeleton. Does bison not test the yacc skeleton against the 
> > Calculator example? If not, I don't have any nice tests to run. In this
> > case, what examples should I run the push parser against?
> 
> Sorry, I don't know the answer to either question offhand.  Perhaps
> you can modify the tests so that the yacc skeleton is tested against
> the calc example.

OK, I made a mistake here. The LALR(1) tests the yacc skeleton.
So, there are 3 pure tests being tested here. I'm going to add 3 push
tests to test the same functionality. 

I did run into a small problem. I'm using yyparse as the function name 
when you do the push parser, instead of something new like yypushparse. 
Do you think I should continue to use yyparse? or should I add a new 
function yypushparse that is generated when %push-parser is specified?

Here is the trouble I've run into. There is an option like this in 
the testsuite:
  %parse-param {semantic_value *result} %parse-param {int *count}
When that is done, apparently bison generates yyparse like this:
  int yyparse (semantic_value *result, int *count);
However, the push parser defines yyparse like this:
  void yyparse (void *PVVOID);

So, I end up getting a compiler error when %push-parser and 
%parse-param are used together.

- Does it make sense to use these options together? (I don't know what
  %parse-param is used for)

- Should I generate a yypushparse function instead to avoid this
  problem?

- Should I make the push-parser handle those extra parameters when
  %parse-param is used? (ie)
  void yyparse (void *PVVOID, semantic_value *result, int *count);

Thanks,
Bob Rossi