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" <[email protected]> wrote: > 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!
