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

[Adrian Vogelsgesang]

Hi Kevin, hi Akim,

I can imagine cases where having a longer list of expected tokens might be 
useful.
However, I wouldn’t like to have them in a string stitched together by bison, 
but instead I would like to have access to them in a std::vector<TokenId> or 
something similar.
That way, I could do some post-processing of the expected token list (e.g., 
expand the “variable_name” token to all variables which are currently in scope).
The result could then be integrated with, e.g., a dropdown list for 
autocompletion pretty nicely :)

Having programmatic access to the list of expected tokens would probably also 
solve Kevin’s request for reporting more than 5 tokens: he could just do it 
himself in his own code after getting the token list from Bison.

Cheers,
Adrian

From: help-bison <address@hidden> on behalf of Akim Demaille <address@hidden>
Date: Wednesday, 6 February 2019 at 10:43
To: Kevin Villela <address@hidden>
Cc: Bison Help <address@hidden>
Subject: Re: Forcing Bison's yacc.c to report more expected tokens on syntax 
error

Hi Kevin,

> Le 6 févr. 2019 à 03:01, Kevin Villela <address@hidden> a écrit :
>
> Hi all, I saw that the yacc.c skeleton only supports reporting a maximum or
> 5 expected tokens. The page
> <https://www.gnu.org/software/bison/manual/html_node/LAC.html<https://www.gnu.org/software/bison/manual/html_node/LAC.html>>
>  on
> Look-Ahead Correction states this is "because of internationalization
> considerations". I was wondering if I would be able to contribute a
> configuration option to increase this number arbitrarily, or even just up
> to a higher number (e.g. 30) ?

The thing is that it's unclear that it actually helps to report all the 
possibilities when there are too many.
_______________________________________________
address@hidden 
https://lists.gnu.org/mailman/listinfo/help-bison<https://lists.gnu.org/mailman/listinfo/help-bison>