Operator precedence in Scala

Question

I like Scala's propose of operator precedence but in some rare cases, unmodified rules may be inconvenient, because you have restrictions in naming your methods. Are there ways to define another rules for a class/file, etc. in Scala? If not, would it be resolved in the future?

Solution 1

Operator precedence is fixed in the Scala Reference - 6.12.3 Infix Operations by the first character in the operator. Listed in increasing order of precedence:

(all letters)
|
^
&
= !
< >
:
+ -
* / %
(all other special characters)

And it's not very probable that it will change. It will probably create more problems than it fixes. If you're used the normal operator precedence changing it for one class will be quite confusing.

Solution 2

Are there ways to define another rules for a class/file, etc. in Scala? If not, would it be resolved in the future?

There is no such ability and there is little likelihood of it being added in the forseeable future.

Solution 3

There was a feature request raised in the typelevel fork of the scala compiler, a version of the compiler which 'previews' experimental features. The developers suggested that if somebody were to write a SIP for this, it may be considered for implementation.

But in it's current state, there is no way to override precedence. It's rules are formally defined in the language specification.

Comments

[Luigi Plinge]

@huynhjl from the cited reference: "There’s one exception to this rule, which concerns assignment operators(§6.12.4). The precedence of an assigment operator is the same as the one of simple assignment (=). That is, it is lower than the precedence of any other operator." §6.12.4 describes an assignment operator as one ending in "=". So the list above is incomplete, rather than incorrect.

[huynhjl]

@Luigi Plinge, === is not an assignment operator because there in an exception: an operator ending in = is an assignment operator unless the operator also starts with an equals character. Look at the gmane thread and the other link, Martin himself indicated that the SLS needed an update. I cannot see an update yet.

[Erik Kaplun]

I think the decision to make (all letters) the "weakest" one is weird: a contains b || c contains d, which I think is a frequent construct, needs parentheses...

[virtualeyes]

@ErikAllik indeed, I agree fully, really makes for pointless noise when working with a DSL that could look like: if(a is b && c is d && ...), but requires if(a === b && c === d && ...) due to precedance rules.

[Jeriho]

by "restrictions in naming your methods" I mean that if, for example, you think that '+' is a perfect name for your method, there can be situations that you whould be forced to choose another name because of unmodifiable precedence.

[Jeriho]

Not all programming languages have unmodifiable operator precedence. Look at haskell's infix/infixr/infixl commands.