parser: make infix : right-associative

[maxteufel]

This makes it easier to create lists using list.infix : because it is now possible to declare a list i32 := 1:2:3:nil instead of a list i32 := 1:(2:(3:nil)).

The big problem with this change is that infix : is also used for boolean implication. In this case right-associativity is unwanted.

[maxteufel]

Note: this pull request is not really intended to be merged, due to the problem mentioned. However, I want this to be discussed because:

1. I like list.infix :, but it should somehow be possible to avoid having to use many parentheses.
2. I also like the bool.infix : syntax for an implication.

[fridis]

One approach would be to allow the user to specify left- or right-associativity in a declaration, i.e.,

infix_left : (other bool) bool is ...
infix_right : (type T, a T, b list T) list T is ...

And then, for an operand expression a ++ b -- c +- d with infix operators of the same precedence, leave the resolution of the order to the call resolution phase, i.e., instead of creating a Call for a + (...) create an InfixOpCall for the whole expression consisting of expressions and infix operators of the same precendence. Then, during call resultion phase, InfixOpCall could lookup the first operator infix ++ on a and, if it is left-associative, convert this into a Call on a and b and use this as the LHS for infix --, otherwise convert this into a Call on a and the right hand side being an InfixOpCall of the remaining b -- c +- d. In either case, an inconsistent associativity for any operator in such an expression should be reported as an error.

[fridis]

Alternatively, the syntax sugar performed in ParsedCall could check that for an infix_right, if the target is also an infix_right operand with same precedence and not in parentheses, then change a.f(b).g(c) into a.f(b.g(c)). This could use some of the infrastructure used for chained booleans.