Re: RFC: variable parse.error

[Joel E. Denny]

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"