[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: document new features of parse.error
From: |
Akim Demaille |
Subject: |
Re: document new features of parse.error |
Date: |
Wed, 29 Jan 2020 18:16:45 +0100 |
Adrian,
> Le 29 janv. 2020 à 11:01, Adrian Vogelsgesang <address@hidden> a écrit :
>
> Hi Akim
>
>> When a true alternative is offered, then we might deprecate verbose.
> makes sense. For now, we could at least put some note in the documentation
> that recommends using
> “detailed” instead of “verbose” for new projects. If I would be a new-comer
> looking into the bison
> docs for the first time, I would probably be confused if I should choose
> detailed or verbose.
That's why I wrote
> @item @code{detailed}
> Error messages report the unexpected token, and possibly the expected ones.
> However, this report can often be incorrect when LAC is not enabled
> (@pxref{LAC}). Token name internationalization is supported.
>
> @item @code{verbose}
> Similar (but inferior) to @code{detailed}.
>
> Error messages report the unexpected token, and possibly the expected ones.
> However, this report can often be incorrect when LAC is not enabled
> (@pxref{LAC}).
>
> Does not support token internationalization. Using non-ASCII characters in
> token aliases is not portable.
I don't want to come too hard too fast on verbose just yet. As a matter of
fact today I had my first PR in PHP, and it was about moving from
YYERROR_VERBOSE to 'parse.error verbose' :)
>> I have proposed […] to generate a CSV file with facts about the tokens […],
>> but received no answer
> As I have no experience with auto-generated scanners, I can’t provide you any
> good feedback on this
> idea, though. In general the CSV file sounds reasonable to me, too (although
> escaping in CSV can be a
> huge time sink. There are a lot of quirks re escaping in various
> implementations such as Python
> libraries, Excel, OpenOffice, … Not sure how bad it is on the “emitting CSV
> side”, I only know the parsing
> side of CSV)
I'm not too afraid about this. But anyway, so far there's no demand.
>> Do you plan to port these features to lalr1.cc?<http://lalr1.cc?>
> Yes, I do.
Great!
> However, I currently don’t have time for it, and depending on your timeline
> and how critical
> the C++ implementation is for you, it might be faster if you do it yourself.
> I would probably need a few weeks before I can look into it
I'll see how I progress in the other skeletons. Thanks!