> Le 8 janv. 2020 à 09:30, Adrian Vogelsgesang <[email protected]> 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!
