Infix notation for function call / invocation.

[Centril]

There doesn't seem to be much support for supporting custom operators (see #818) in Rust. But what about calling normal binary functions as if they were operators, like haskell allows you to?

The syntax would be:

a `dot` b

to convey scalar product of two vectors a and b.

Another option suggested by @bluss:

a \dot b

Or if it possible without parsing conflicts (@thepowersgang: "but probably not dersirable"):

a dot b

Which is converted to

a.dot( b )

or, depending on the function:

dot( a, b )

[ticki]

This is a TIMTOWTDI feature with very little (any?) gain. It doesn't read terribly well either.

[Centril]

Also discussed in: rust-lang/rust#8824

[Centril]

TIMTOWTDI = There's more than one way to do it

There's nothing inherently wrong with having more ways to do one thing.
Some prefer reading a dot b to a.dot( b ) since it gives a more "mathematical" feel to it.

[bluss]

a \dot b is the nicest syntax I have seen proposed for this (taken from the previous discussion).

The idea is to introduce one more operator to end all custom operators. Instead of defining custom operators, we can just use functions for this purpose.

I know the argument that methods are infix, x.dot(y) is infix. The infix binary function call proposal has advantages:

• Functions already support: namespacing, importing and renaming. Functions can also use their own traits that they defined for the operands, so we get quite a lot of flexibility by reusing an abstraction we already have (functions are great!).
• It staves off parenthesis build up. Methods may result in nested calls like x.dot(y.dot(z.dot(w)))).
  • x \dot y \dot z \dot w is easier to read and even a parenthesized infix call version is easier to read: x \dot (y \dot (z \dot w)).
• Free functions can use a conversion trait bound on both arguments, where methods can not do that for the self argument.

[ketsuban]

It doesn't seem beyond the wit of man that someone might reasonably expect a library-defined operator whose return type is the same as that of the first operand to be usable as an augmented assignment. How easy is that to do?

[Centril]

Discussion on fixity from IRC, for future reference...:

151205            vfs | Centril: are those to have some hard-coded precedence?
151242          bluss | Centril: if you want to. You can just say that either one or the other is a possible
                      | implementation
151301          bluss | proposals like this are judged from superficial issues like syntax too
151321        Centril | vfs: it would have to I guess, how high it should bind I don't know yet
151331          bluss | I mean, the syntax is important in the end, but it doesn't decide if the feature is worth
                      | having or not by itself
151357        Centril | bluss: would it be possible to skip the \ alltogether and just have a dot b ?

                                                            [...]

151924            vfs | Centril: what about associativity? bluss comment seems to suggest right associative, but
                      | afaik all rust operators are all left associative.
151942        Centril | vfs: haskell says:
                      | http://stackoverflow.com/questions/8139066/haskell-infix-function-application-precedence
151956        Centril | infixl 7 `dot`
152204          bluss | vfs: wouldn't the comment suggest left associative, if the (x (y  z)) version is the one
                      | needing explict ()'s
152220        Centril | so in haskell, a `plus` b `plus` c == (a `plus` b) `plus` c
152256            vfs | bluss: `x.dot(y.dot(z.dot(w))))` <-- this does if i read it correctly
152353        Centril | vfs is correct that it is right associative because it evaluates z.dot(w) fist
152357          bluss | anyway, it's not intended to suggest anything
152453        Centril | vfs bluss: one could (possibly) add an attribute to a function specifying its fixity if a
                      | default one isnt good
152533            vfs | what if function is in another crate?
152549       oli_obk_ | Centril: and how would that work together with other infix functions?
152636        Centril | vfs: then the fixity information would have to be carried over into the metadata in some
                      | way i guess
152644          bluss | vfs: the attribute should be on the function
152655          bluss | You'd use this with a function intended to be callable infix
152754        Centril | or, maybe you could know if it is left associative or right depending on where \ is, so x
                      | \dot y or x dot\ y
152807        Centril | maybe thats a bad idea, just brainstorming atm
152828        Centril | oli_obk_: ideas :) ?
152842            vfs | bluss: so you would need to external crate metadata to know how to parse an expression?
                      | (maybe it is the case already now, idk)
152917          bluss | vfs: that's a good point, that doesn't sound workable to me
152919        Centril | guess we need someone who knows the compiler better to flesh that out
152931          bluss | even if crates can inject macros etc
152947        Centril | so maybe it a better idea to specify fixity at call site?
153039       oli_obk_ | Centril: you can't decide it globally. So you can say that a function has a higher fixity
                      | than another function. This way you get a tree of rules depending on the crate dependency
                      | tree. Similar to impl orphans
153117       oli_obk_ | Centril: then you can simply force infix to require brackets if you're specifying it at
                      | the call site
153129       oli_obk_ | and if you are doing that, you can go the macro way
153212       oli_obk_ | a `$lhs:expr $fun:path $rhs:expr` => { $fun($lhs, $rhs) } rule should do it
153255        Centril | so, umh, rephrase .P ?
153351       oli_obk_ | which part? the one about fixity at the call site or the fixity tree?
153423        Centril | all of the above :P
153555       oli_obk_ | if you want to specify the fixity at the call site, you can simply use brackets and force
                      | them. so it would be something like `\(a dot b)` transforms to `dot(a, b)`, but then you
                      | don't gain much over macros: `i!(a dot b)` might be possible, maybe one needs `i!(a \dot
                      | b)`
153722       oli_obk_ | if you want to specify the fixity at the definition site, you need to specify it for all
                      | infix functions that your infix function can be in the same expression with. That might
                      | not be very feasible, but at least complete.
153724        Centril | well, if you have a default fixity, say infixl, then you can write a \dot b \dot c , or
                      | force it: a \dot (b \dot c)
153822        Centril | oli_obk_: haskell does it at definition site, but it has a default fixity of infixl 9
153902       oli_obk_ | that works if you only have one function
153914       oli_obk_ | but what about `a \foo b \bar c` ?
153921        Centril | problems =)
153932        Centril | or: first come first served
154108       oli_obk_ | Centril: what about `vec \add_each_value vec2 \mul_each_value vec3` ? (in matlab terms:   
                      | `vec + vec2 .* vec3`
154206        Centril | well yes, that isnt so nice since that would eval to (vec1 .+ vec2) .* vec3

                                                            [...]

154759        Centril | oli_obk_: but i think that left associative with first-come-first-serve still might be a  
                      | good simplification that makes it crystal clear
154831        Centril | otherwise you have to read about the fixity in the documentation, etc.

[bungcip]

I like custom infix operator as long as limited in ascii letter. But I don't like if you can turn any arbitrary function to infix call. When I create function foo, I expect the function to be used like this: foo(a,b). When I want to create custom infix notation, I expected to implement the necessary trait.

see previous discussion in https://users.rust-lang.org/t/infix-functions/4724

[durka]

Does it interact with generics? Would we end up with a \dot::<Foo<'a>, Bar> b?

[Centril]

@durka Probably, you'd have to specify it somehow with generics, and what you've come up with seems best. But I guess you'd save \dot for cases when the types can be inferred from the Exprs.

[strega-nil]

I don't want this in the language. I think it adds a lot of complication, and it's unimportant to me personally. However, I wouldn't be too opposed to this. It seems nice, especially, for mathematical code.

[brendanzab]

Infix functions are great in languages like Haskell where operators are more common, but it doesn't seem to give Rust much.

[alilleybrinker]

Are there examples of projects where this would result in a decent ergonomic improvement?

[Centril]

@AndrewBrinker I venture a guess that writing mathematics libraries, e.g: linear algebra, and using them, as well as the low level parts of physics engines might benefit from the increased ergonomics.
Essentially, inside and outside anywhere where a lot of math is needed.

There might be other projects of course, but off of my head, that's the typical use case.

[ticki]

@Centril The existing overloadable operators covers 95% of those use cases.

[burdges]

Would this mean we could write obfuscated code that compiled both in Rust and TeX? ;)

I love the infix operator notation in Haskell, partially because not all mathematical operators to *, +, etc. even when mathematicians write them that way. I love Haskell's lack of parentheses on function calls too though. Yet, Rust is a rather different language, so tools like currying do not always fit.

At first blush, I'm thinking one should start with just knowing when to avoid, or argue against, using object . notation around mathematical objects. If for example, we're doing an action, scalar multiplication, etc. then object notation looks like a left action, which gets annoying if you are not a group theorist from Britain or something.

I fear this proposal makes the left vs right action issue worse. In other words, a \dot b might be more useful for mathematics as b.dot(a) than as a.dot(b), but that seems confusing in non-mathematical situations.

In the long run, one could probably build a strict functional language with Haskell-like syntax, maybe an Idris fork, that compiles to Rust code, but does not introduce a garbage collector. I'd suspect that's a better way to build DSLs that compile to Rust.

[gbutler69]

It'd be helpful if the relevant parts were explained, so that a Haskell noob like me could follow.

In that case, asking the commenter to clarify is highly desirable and appropriate. Calling it off-topic and saying that the comments don't belong because they are off-topic is not. Again, "Prior-Art" is 100% on-topic in any proposal. I just can't see how it couldn't be.

[Centril]

I'm suspecting @ubsan was half-joking?; I don't mind their comment at all ❤️

@MajorBreakfast

It'd be helpful if the relevant parts were explained

Sure thing! (and some bonus parts)

EDIT: I hope this was helpful / understandable; if it wasn't, let me know =)

Let's start simple.

-- Equivalent (up to memory representation) to `enum List<a> { Nil, Cons(Box<List<a>>), }`.
--
-- List is a type constructor from  Type -> Type;
-- List Int is applying 'Int' to 'List' giving you back a type.
-- 'a' is a type variable (generic type parameter)
-- 'Nil :: List a' is a data constructor 
-- 'Cons :: a -> List a -> List a' as well.
data List a = Nil | Cons a (List a)

length :: List a -> Int   -- A function from List of 'a's to 'Int'
length Nil = 0 -- pattern matching on Nil
length (Cons _ xs) = 1 + length xs -- Pattern matching on Cons.

-- explicit quantification of the type variable 'a'
length :: forall a. List a -> Int
length xs = case xs of  -- similar to 'match'
    Nil -> 0
    Cons _ xs -> 1 + length xs

-- A binary function from 'a' to 'a' to 'a'
-- proviso that 'a' satisfies the 'Num' typeclass (trait);
plusMul2 :: Num a => a -> a -> a
-- This is the same; Haskell functions are curried!
plusMul2 :: Num a => a -> (a -> a)
plusMul2 x y = (x + y) * 2

Rust equivalent of the last one (up to currying, laziness, memory model..):

fn plusMul2<A: Add + Mul>(x: A, y: A) -> A {
    (x + y) * 2
}

With respect to the example lens operators:

(+~) :: Num a => Lens s t a a -> a -> s -> t

-- explicitly quantified type variables and explicitly showing the currying:

(+~) :: forall a s t. Num a => Lens s t a a -> (a -> (s -> t))

This declares (the type of) the infix ternary custom operator +~ which takes a value of type Lens s t a a a value of type a and a value of type s and produces a value of type t. The lower case a, s, and t are type variables (parameters). Lens :: Type -> Type -> Type -> Type -> Type is a type constructor taking 4 types as arguments and returning a type. Again, a must satisfy the Num trait / type class.

whatever = (field3 %~ reverse) . (field2 .~ baz) . (field1 .~ bar)

This defines a top level function whatever; The . are function composition.

More details: https://hackage.haskell.org/package/lens
and: https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial

[MajorBreakfast]

In Kotlin, functions marked with the infix keyword can be called with the infix notation: https://kotlinlang.org/docs/reference/functions.html#infix-notation

[nielsle]

Here are a few arguments for placing this feature in a library rather than in the core language

The syntax looks slightly alien compared to the rest of rust and it is not very googleable, but if we force the programmer to decorate each function with #[linalg_dsl] or something similar, then the reader has a chance to google for the decorator and discover what is going on.

I will probably only be using the feature in a few math-heavy functions, so at least for me it doesn't require a lot of work to decorate each function separately.

If we end up with several competing macro libraries with varying syntax, then we have a change to pick the best one.

[Centril]

@nielsle

The syntax looks slightly alien compared to the rest of rust

Certainly no more alien than the operators the language already has?

it is not very googleable,

Haskell uses custom search engines (hoogle) to provide you with much better results than google could ever provide. I believe we could do the same.

Decorating functions with a proc macro such as this has the problem that proc macros are a very heavy weight DSL authoring mechanism; it costs a lot to make such a DSL. Meanwhile, custom operators, or functions with infix function notation such as in Haskell are extremely easy to make new ones of.

[nielsle]

Would it be possible to define a macro for defining infix dsls? Something like this could be useful.

// In library
pub fn dot( .., ..) -> .. { ..}
pub fn cross( .., ..) -> .. { ..}
define_infix_dsl!(my_linalg, [dot, cross])

// In code
#[dsl(my_linalg)] 
fn foo() {..}

[Centril]

Would it be possible to define a macro for defining infix dsls? Something like this could be useful.

Let's experiment ;)

[MajorBreakfast]

@nielsle In a DSL, the infix call style could just be enabled for all methods (with a self param and one other param)

[masaeedu]

I'm trying to find a language that I can write vector math and graphics stuff in more easily than in C++, while retaining good performance. With respect to the people that have commented here saying infix operators are useless or nearly so, the ability to define and use infix operators of well specified fixity makes quite a significant difference in writing legible math-related code and avoiding mistakes.

[sighoya]

@Centril

Why not decide associativity by vararg functions (at definition time) and when they don't exist, then assume by default left associativity.

Note, there are functions which are neither right nor left associative, e.g. the cartesian product:

A*B*C=*(A,B,C) != (A*B)*C /\ *(A,B,C) != A*(B*C)

[joshtriplett]

I would still love to see something like this happen, but there hasn't been activity in this issue for several years, and RFC issues (as opposed to PRs) aren't really a good forum for this kind of thing. I'm going to close this, but I'd encourage people who are interested in it to collaborate on an MCP for it.

[wishawa]

If you really want to, you can make infixes like these

x ^pow^ y;
a *dot* b;
a *cross* (b *cross* c *cross* d);

in stable Rust today by abusing operator overloads.

Example code:

use std::ops::Mul;

#[allow(non_camel_case_types)]
struct dot;

struct DotPartial<const N: usize>([f32; N]);

impl<const N: usize> Mul<dot> for [f32; N] {
    type Output = DotPartial<N>;
    fn mul(self, _rhs: dot) -> Self::Output {
        DotPartial(self)
    }
}

impl<const N: usize> Mul<[f32; N]> for DotPartial<N> {
    type Output = f32;
    fn mul(self, rhs: [f32; N]) -> Self::Output {
        self.0.iter().zip(rhs.iter()).map(|(a, b)| a * b).sum()
    }
}

[PacificBird]

Wow, this is super creative and in my opinion looks pretty good too! While at some point in the future it would be nice to have a prettier way to do this, I think most of the use cases that custom infix functions would be good for can make use of this today (such as the dot product, as you demonstrated!) Since it looks like pretty much every implementation of this would be really similar, I'm wondering if you could make a declarative macro would would write this out for you. I may try my hand at this later.

[PacificBird]

I have implemented the aforementioned macro and published it in a crate here on crates.io. Any infix operator with a static input type is now a one-liner to define!

EDIT: Only problem is Rustfmt screws with it and there's no way to disable the operator spacing.