Re: push parser implemenation

[Bob Rossi]

On Thu, Sep 14, 2006 at 11:57:34AM -0700, Paul Eggert wrote:
> Bob Rossi <address@hidden> writes:
> 
> > Do you like the name yypushparse ()?
> 
> Sounds good to me.
> 
> > How should I handle the %parse-param option in %push-parser mode? Should
> > the yyparse () function and the yypushparse () function both accept the
> > %parse-param arguments?
> 
> Sorry, I don't understand the issue well, but if both kinds of parsers
> are likely to want to accept user-defined arguments in order to do
> their work, then I suppose they'll both need to support %parse-param
> similarly.
> 
> If you think it unlikely that a push parser would ever need to have
> %parse-param, then you can instead cause an error message to be
> generated if %parse-param is specified with a push parser; we can add
> the feature later if it turns out we were wrong.

Honestly, I don't understand why a pull parser needs this feature. If
the only reason the pull parser had extra parameters via %parse-param
was to pass those parameters to the lexer, then the push parser doesn't
need this feature, since the user calls the lexer directly. Otherwise,
I haven't changed anything that I know of in regards to having extra
parameters in the yyparse function. I have never used the %parse-param
feature, and therefor don't understand why it would be useful at all.
I do not have a problem implementing this feature for the push parser
now, since I don't think it would be much effort just to change the
prototype. So, I suppose I'll just add it and hope everything works. 

In the case when the user issues the %push-parse option, I'll have to
make sure the yyparse () function passes the %parse-param's along to
the yypushparse () function. Is there an easy way to get the "names"
of the parameters from the %parse-param option instead of getting
the "type and the name"? Without this functionality, it'll be hard to
do. I'd imagine if the functionality existed, it would be pretty easy to
break also.

Thanks,
Bob Rossi