On Thu, Sep 14, 2006 at 11:57:34AM -0700, Paul Eggert wrote: > Bob Rossi <[EMAIL PROTECTED]> 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
