Re: are there user defined infix operators?

[Hans Åberg]

> On 8 Nov 2018, at 20:21, Uxio Prego <address@hidden> wrote:
> 
>> You can write general rules say for prefix, infix, and postfix operators, 
>> [...]
> 
> For simplicity I would be happy to consider only infix operators.

For fixity overloads (same name but different fixity), one can have the 
overloads used in C/C++: prefix and postfix (as in ++), or prefix and infix (as 
in -), but not infix and postfix. This requires extra processing, keeping track 
of the token that was before; Bison cannot do that, so the lexer must do it. A 
grammar might look like, with the lexer figuring out what to return:

%left binary_operator
%left prefix_operator
%left binary_or_postfix_operator
%left postfix_operator

%%

expression:
    value
  | prefix_operator expression
  | expression postfix_operator
  | expression binary_or_postfix_operator // Postfix operator
  | expression binary_or_postfix_operator expression // Binary operator:
  | expression binary_operator expression
;

>> [...] 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?

Take a simple example, a + b*c #, where # is the end marker. First put the a on 
the value stack, and the + on the operator stack, and then the b on the value 
stack. When the * comes by, it has higher precedence than the + on top of the 
operator stack, so it must be stacked. Then the c comes by, so put it on the 
value stack. Finally the end marker #, which has lower precedence than *, so 
let * operate on the value stack, and put back its value, b*c. Next is the +, 
and # has lower precedence, so + operates on the value stack, computing a + 
(b*c), which is put back onto the value stack. Then the operator stack empty, 
so the process is finished, and the value stack has the value.

One can also use a single stack, and an operator precedence grammar [1]. It 
might give better error reporting, but then you need to figure out how to 
integrate it into the Bison grammar.

1. https://en.wikipedia.org/wiki/Operator-precedence_grammar