Hey, thank you very much! I had lost all faith. > You can write general rules say for prefix, infix, and postfix operators, > [...]
For simplicity I would be happy to consider only infix operators. > [...] the actions put them onto to a stack with precedences and another for > values. Then, when a new operator comes by, let the operators on the > stack with higher precedences act on the value stack until something with > a lower precedence appears, [...] I read this twice and didn't understand anything. I read it once again and now I understand you are proposing that when operators are used, I don’t really use the syntax tree I'm generating with Bison _straightly_, but a more complex syntax tree I'd be generating combining the natural tree that arises from the grammar and other information in those data structures you propose. Did I understand that right? > On 8 Nov 2018, at 14:48, Hans Åberg <haber...@telia.com> wrote: > > >> On 2 Nov 2018, at 17:53, Uxio Prego <uxio.pr...@gmail.com> wrote: >> >> More specifically, I'm curious to know if Bison can modify precedences >> at parsing time according user sentences, now referring as user not the >> programmer who wrote the *.y doc but the programmer writing a program >> parsed by the parser generated from the *.y doc. > > You can't but: > > You can write general rules say for prefix, infix, and postfix operators, and > then the actions put them onto to a stack with precedences and another for > values. Then, when a new operator comes by, let the operators on the stack > with higher precedences act on the value stack until something with a lower > precedence appears, and put the new operator onto the stack. Continue until > the end symbol comes by that has the lowest precedence. Operator > associativity is handled by viewing left and right hand side precedences as > different. > > _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison