Re: Forcing Bison's yacc.c to report more expected tokens on syntax error

[Kevin Villela]

Thanks everyone for your responses! You hit the nail on the head, ideally I
would ideally want access to the list of tokens.

Akim, I understand your concerns about making API changes. However, I think
the change described by Derek is actually additive - that is, we would
still by default give the existing behavior, but would also provide the
option for users to override this default behavior by providing their own
syntax error function. Would something like that be possible? AFAICT the
other issues (internationalization, escaping) are actually orthogonal to
providing a new syntax error function option (but please correct me if I'm
wrong).

On Wed, Feb 6, 2019 at 12:07 PM Akim Demaille <address@hidden> wrote:

> Hi all,
>
> > Le 6 févr. 2019 à 20:53, Derek Clegg <address@hidden> a écrit :
> >
> > I agree with Adrian — it would be nicer, in my opinion, to allow users
> to handle syntax errors directly, rather than always going through the
> bison code which formats syntax errors in a fixed way.
>
> I also agree with this idea.  But it's not that simple to change the
> existing API, and the last time I asked for comments, I had nothing (
> https://lists.gnu.org/archive/html/bison-patches/2018-11/msg00030.html,
> https://lists.gnu.org/archive/html/bison-patches/2019-01/msg00037.html).
> Also, the way to denote the culprit (the invalid token) is quite delicate
> (except for the obvious case of keywords).
>
> I will be back on this issue _after_ I have found a satisfactory answer
> about internationalization, and escaping.