Hi Akim. Sorry to be so late replying. On Tue, 23 Jun 2009, Akim Demaille wrote:
> I am still slowly trying to normalize the name of the variables we will use in > Bison 2.6. This patch deprecates %error-verbose in favor of %define > parse.error "verbose". > > I think "parse.error" is ok, but I'd be happy to receive other proposals. How about parse.error.messages or parse.error-messages? One day we might have, for example, parse.error.recovery to specify the recovery mechanism. > I > am less satisfied with "simple" and "verbose". "simple" is ok, but it could > be "constant" for instance. Or "yacc" for that matter (actually I don't know > if POSIX mandates the format of the error message). POSIX does say "syntax error". However, I think the Bison user who doesn't care about Yacc shouldn't have to consider what Yacc does, so we should choose something more explicit. I'm not sure the meaning of "constant" is obvious at first, but it's ok. I think "simple" clearly summarizes the most important point: this value produces the least sophisticated error messages. > "verbose" is not too good, as it is very vague, and can easily denote many > other strategies for error-messages. I agree. > What will we put if some day we allow > the user to hook the generation of error messages (for instance to specify how > to display the "unexpected" token)? Are you thinking there will be multiple properties that can be configured independently? %define parse.error.messages.token "hide" %define parse.error.messages.token "show" %define parse.error.messages.value "hide" %define parse.error.messages.value "show"
