Operator precedence in Heron is tricky, because any sequence of legal operator characters is a legal operator.
At the present moment I leaning towards setting operator precedence in Heron :
unary expressions (prefix operations)
multiplicative * / %
additive + -
Here is the problem I am facing: In Heron there are no predefined operators. Any sequence of operator characters is in fact a legal operator. All operators map to a specifically named member function of the left hand value.
An example of a problem with just following C++ operator precedence rules is that an overloaded pipe operator (|) might actually mean to create a pipe and not bitwise or. Even > could have multiple meanings like redirect output to a file or greater than. Giving it a specific precedence based on usage of bitwise or is not a good idea. What about entirely new operators, like &&= which means assignment boolean and. It should be at the same level as the other assignment operators. Anyway the list of complications goes on and on. I think beyond the simple arithmetic precedence rules, it is best if I rely on disamibguation rules.
Maybe there is another way that everyone can be happy: I wonder if there there is an elegant way to implement precedence directly within a language? Maybe there would be an expression reordering step, that is controllable from code. Perhaps something inspired by expression template machinery? Perhaps operators could map to types or function pointers?
I am open to new ideas here.
The precedence of an infix or split operator says how it "behaves" with respect to other infix or split operators. We seem to need at least two "layers", each having at least three precedence "strata" -- additive, multiplicative and exponential. Think of the usual syntax for boolean combinations of arithmetic equations. Here we have +,*,^ for expressions, then equality lower than all these, then +,*,^ for propositions. It seems reasonable to allow for 10 levels, although this is certainly rather `ad hoc'. This happens to be as in Haskell.
This is not particularly elegant. I would be happier telling programmers to use parantheses to disambiguate precedence.