Re: how to get left hand side symbol in action

[Christian Schoenebeck]

On Freitag, 10. Mai 2019 19:43:03 CEST Akim Demaille wrote:
> > Le 10 mai 2019 à 16:28, Christian Schoenebeck <address@hidden>
> > 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