[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: custom error messages

From: Akim Demaille
Subject: Re: RFC: custom error messages
Date: Wed, 8 Jan 2020 22:13:14 +0100

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]