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?

Fulgurate

Related mailing list thread: scala-programming-language.1934581.n4.nabble.com/… – Mendelson

Answer 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.

Wench

@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. – Attah

@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. – Blame

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... – Lou

@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. – Imena

Answer 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.

Richelieu

Answer 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.

Eugenioeugenius

Answer 4

unmodified rules may be inconvenient, because you have restrictions in naming your methods

• you do not have any restrictions in naming your methods. For example, you can define methods +, -, * and etc. for a class.
• we must also follow de-facto "unmodified rules" (enforced by Scala operator precedence rules) mentioned in previous answer (https://stackoverflow.com/a/2922456) by Thomas Jung - it is common for many if not all programming languages, and abstract algebra; we need not redefine operator precedence for a+b*c.

See Chapter 6 of the book http://www.scala-lang.org/docu/files/ScalaByExample.pdf for "Rational" class example.

Kummerbund

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. – Fulgurate

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