Re: custom error messages

[Adrian Vogelsgesang]

Hi Akim,


> 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

Cheers,
Adrian



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,



    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!