50

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jeriho
  • 7,129
  • 9
  • 41
  • 57
  • 3
    Related mailing list thread: http://scala-programming-language.1934581.n4.nabble.com/More-unicode-alternatives-for-ASCII-operators-td2008146.html – retronym May 27 '10 at 19:53

4 Answers4

105

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.

Jasper-M
  • 14,966
  • 2
  • 26
  • 37
Thomas Jung
  • 32,428
  • 9
  • 84
  • 114
  • 6
    @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. – Luigi Plinge Sep 29 '11 at 14:35
  • 7
    @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. – huynhjl Sep 29 '11 at 15:14
  • 1
    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... – Erik Kaplun Feb 16 '14 at 23:23
  • 1
    @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. – virtualeyes Feb 20 '14 at 11:17
8

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.

serv-inc
  • 35,772
  • 9
  • 166
  • 188
Randall Schulz
  • 26,420
  • 4
  • 61
  • 81
2

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.

Luciano
  • 2,388
  • 1
  • 22
  • 33
0

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.

Community
  • 1
  • 1
Fuad Efendi
  • 155
  • 1
  • 9
  • 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 Apr 27 '17 at 22:08
  • 1
    Not all programming languages have unmodifiable operator precedence. Look at haskell's infix/infixr/infixl commands. – Jeriho Apr 27 '17 at 22:13