Re: RFC: %param

[Paolo Bonzini]

> > I was tired to read
> >
> > > %parse-param {::parser::ParserImpl& up}
> > > %lex-param {::parser::ParserImpl& up}
> > > %parse-param {yyFlexLexer& scanner}
> > > %lex-param {yyFlexLexer& scanner}
> >
> > in my code, I wanted
> >
> > > %param {::parser::ParserImpl& up}{yyFlexLexer& scanner};
> >
> > I pushed this feature in candidates/%param, but there are several issues:
> >
> > - I had not noticed, but when I started upgrading the documentation, I
> > discovered that in lalr1.java, the %lex-params are added to the
> > signature of yyparse, which in my case would have allowed to use only
> > %lex-params. It makes sense, but I am uncomfortable with the
> > coexistence of several conventions within Bison.

The lex-params are added to the signature of the constructor only if the 
lexer class is made private within the parser.  Otherwise they're not 
there at all.

In other words, for the Java skeleton you choose between lex-param and 
parse-param in the Java skeleton depending on whether you're going to 
access the param in actions or "%code lexer" blocks.  But you do not 
need to store them as members of the parser class, which is why I do not 
declare them as parse-params.

It would be possible, with a slight inefficiency, to store them as 
members of the parser class as well.  Then you'd be able to remove them 
from the parser prototype and mimic the C++ behavior.

Paolo