Re: RFC: custom error messages

[Akim Demaille]

> Le 8 janv. 2020 à 09:30, Adrian Vogelsgesang <address@hidden> a écrit :
> 
> Hi Akim,

Hi Adrian,

>> With "%define parse.error rich" (for lack of a better idea,
>> suggestions most welcome), …
> 
> To me, not having double quotation is rather a property
> of the token table and not of error reporting. So, I am
> wondering if it would be cleaner to extend %token-table
> instead of %parse.error.

I don't know what you understood about my proposal, but my plan
is to remove the extra level of quotes in yytname when parse.error
is 'rich' or 'custom'.

> E.g., extend the %token-table to have the 3 values
> * %token-table none
> * %token-table quoted: the currently existing variant
>  which introduces quotes
> * %token-table unquoted/%token-table plain: the new,
>  unquoted variant
> 
> and then have 3 modes for parse.error:
> * simple: works with all token-table modes, as it doesn’t
>  even access the token table
> * verbose: compatible “quoted” or “plain” mode. If
>  token-mode is “plain”, the quotes could still be added
>  when formatting the error message
> * custom: compatible with all token-table modes from
>  bison’s point of view. It is up to the author of the
>  grammar to make his error reporting work with the
>  chosen token-table style.
> 
> That way, the proposed “parse.error rich” would simply
> be the combination of “parse.error verbose” with
> “token-table plain”.

I want to keep the combinatorial explosion as reduced as possible.
Testing Bison is already hard enough as is.  And I do not want to
encourage the use of yytname to write scanners, to me this is a dead
end.  So it is on purpose that I bind the new cool error messages
with staying away from yytname-for-yylex and its associated double
quoting.

Cheers!