[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: custom error messages
Re: custom error messages
Wed, 8 Jan 2020 21:30:12 +0000
> 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'.
yes, I also understood it that way.
I was just wondering if it makes this coupling between parse.error and
yytname makes sense and if it wouldn’t be better to keep them two
separate concepts with separate settings.
> I want to keep the combinatorial explosion as reduced as possible
I completely agree and that makes a lot of sense to me.
With that motivation, coupling parse.error and the format of
yytname makes sense.
> And I do not want to encourage the use of yytname to write
> scanners, to me this is a dead end
I think this is the part of information which I missed. I thought you
were still not sure if yytname would be the right way to go or not.
I have no overview about the potential solutions re. generating
scanners based on the grammars – sorry for the noise
On 08/01/2020, 22:13, "Akim Demaille" <address@hidden> wrote:
> Le 8 janv. 2020 à 09:30, Adrian Vogelsgesang <address@hidden> a écrit :
> Hi Akim,
>> 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