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

2019-02-06 Thread Kevin Villela
Hi all, I saw that the yacc.c skeleton only supports reporting a maximum or 5 expected tokens. The page on Look-Ahead Correction states this is "because of internationalization considerations". I was wondering if I would be able to cont

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

2019-02-06 Thread Akim Demaille
Hi Kevin, > Le 6 févr. 2019 à 03:01, Kevin Villela a écrit : > > Hi all, I saw that the yacc.c skeleton only supports reporting a maximum or > 5 expected tokens. The page > on > Look-Ahead Correction states this is "because of intern

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

2019-02-06 Thread 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 or something similar. That way, I could do some po

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

2019-02-06 Thread Derek Clegg
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. This seems like it might be not too hard to do: replace the code starting with char const* yyf

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

2019-02-06 Thread Akim Demaille
Hi all, > Le 6 févr. 2019 à 20:53, Derek Clegg 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. B

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

2019-02-06 Thread 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