On Freitag, 10. Mai 2019 19:43:03 CEST Akim Demaille wrote: > > Le 10 mai 2019 à 16:28, Christian Schoenebeck <[email protected]> > > a écrit :> > > On Freitag, 10. Mai 2019 06:57:00 CEST Derek Clegg wrote: > >> In fact, I do not think error messages in the generated parser should be > >> provided by bison, except as a trivial default. Instead, I’d like to see > >> bison call a function (which I provide) when a syntax error occurs, with > >> a > >> list of what was expected along with what was encountered. Obviously, > >> they > >> should be provided without translation. That would be the most flexible. > > > > Yep, I can just agree. > > Except that you don't. The API that was proposed initially did not > fit your need. At least, that was my understanding of > > https://lists.gnu.org/archive/html/help-bison/2019-02/msg00018.html
Touché, that was too short, sorry. My "agree" was about the modular approach of providing error messages in a flexible and custom way, not on the precise interface that had been suggested in that old post. My old concerns still apply, that is I still find a push design (that is you call Bison API functions you need explicitly in your yyerror() implementation to get just the information you need for the error message) more appropriate, flexible, powerful and API stable than a pull design (where you would get a predefined list of information passed to your yyerror_whatever() implementation; like eat it or leave it). The push design has various advantages. E.g. Bison can easily be extended with new API functions if somebody needs another information, without breaking the previous API and people's existing yyerror() implementations. No matter what kind of arguments Bison would pass to that suggested yyerror_*() function today, I am sure later on people would ask about different information to be provided by Bison as well, or in a different way. Some of them might even be exotic from your point of view, but legitimate for certain use cases, some might become replaced & deprecated, etc. Plus developers could duplicate and modify the parser state without touching the current state to see potential future information, etc. > Listen guys (Derek, Christian): how about you submit a patch of what > you think the feature should be? Then it will be _much_ easier to > discuss. First, agree together (you two), then see what is the reaction > here, including mine, obviously (since in practice, AFAICT, nobody > else is offering to spend time to maintain Bison :-). Before sending any patch, there are various high level questions that would have to be clarified first. These are not minor changes but rather would imply a huge diff. At least for the purposes that I commonly need them for. I mean when you look at the example I gave to you, you might see what I am commonly doing right now to achieve the features discussed. I have like 700 lines of C++ code of (somewhat) generalized parser code (e.g. functions walkAndFillExpectedSymbols(), yyPushParse()) that I more or less just copy and paste to the individual .y source files whenever I need the discussed features. And then I have use case specific code (in the provided example e.g. functions yyerror() and lscpParserProcessShellInteraction()) which call those generalized functions and provide/process the results for the use case specific and individual parser needs. So what I could imagine is that the generalized functions could become available in stock skeletons for convenience, in whatever precise form, language and interface representation. But then again, you might have completely other opinions if and how these kinds of functionalities might become available in Bison or you might question my purposes at first place. Best regards, Christian Schoenebeck _______________________________________________ [email protected] https://lists.gnu.org/mailman/listinfo/help-bison
