Rethink fixity for operators


With the addition of the infix modifier, the language is giving more control in the hands of the developer to define, declaratively, syntactic rules when designing eDSLs. This is a welcome move! I would like to suggest that it is only two steps away from giving full control to the developer and, now that Scala developers have grown used to infix operators, there is demand for rethinking the following:

  • associativity: the rule that : on the left or the right of the infix operator defines whether the operator is binding left or right is a nice visual cue for starters, but it does not work in all cases and becomes annoying when you know what you are doing. The first example that comes to mind is the function operator at the type level (=>), which is only right-associative because of a special rule in the compiler. But if I want to define a symbol for partial functions and I want it to look like the one for functions, something like *=> will be left-associative.

  • precedence: while I think the precedence rules in the language specification have been created for simplifying the choice of symbolic operators, and perhaps prevent library authors to go completely loco and repel newcomers to the language, I think it is safe to say that today there is a mature and wise community of developers who know what they are doing and look with envy at languages like purescript, where precedence is defined declaratively, locally, to accommodate the language rules that make sense at that time and at that place.

  • going beast mode with mixfix: could Scala become the first language that commodifies the definition of custom ternary operators? I wonder…

I mean, come on, you did go ahead with optional braces syntax despite a lot of push back, I know that secretely you want the above :stuck_out_tongue_winking_eye:


I tried implementing macro-based mixfix operators in 2014:

Slides: Mixfix & adjectives using Scala macros

Code: GitHub - hunam/scala-mixfix: Mixfix notation for Scala

The most obvious shortcoming: I ended up using whitebox macros, so not IDE friendly