[RFC] Make the receiver of the piped calls (|>) always the first argument

[Sija]

At the moment it's being passed as the last one.

Passing it as the first argument would IMO give the following benefits:

• Predictable calling convention - first argument position is constant, in contrary to the last - which requires knowing all the others
• Conformity with other languages using pipe operator - see Elixir
• More natural looking calls - Array.any([1, 2, 3], (number : Number) : Bool { number % 2 == 0 })

[gdotdesign]

In Mint it's the last mostly because of partial application:

module A {
  fun (a : String, b : Number, String) {
    a + Number.toString(b)
  }
}

A.a            /* Function(String, Number, String) */
A.a("Hello")   /* Function(Number, String) */

0 |> 
A.a("Hello")  /* "Hello0" */

So basically the pipe is: x |> f <=> f(x) meaning its a syntax sugar for method calls (https://github.com/mint-lang/mint/blob/master/src/ast/pipe.cr#L13)

---

Did a little research what other languages do:

ReasonML:

They have two operators -> for first |> for last.

x -> f(y, z) <=> f(x, y, z)
x |> f(y, z) <=> f(y, z, x)

Elm:

It's the last and they have two |> and <|.

x |> f <=> f x
f <| x <=> f x

PureScript

It's the last.

x # f <==> f x

F#:

It's the last.

x |> f = f x

Elixir:

It's the first.

x |> f = f x

Haskell:

It's the last.

x . f = f x

---

So this is basically function composition https://en.wikipedia.org/wiki/Function_composition_(computer_science)

What I was thinking on making it easier to use is:

• keep it as putting it in the last argument
• have a placeholder element _ for where the argument would go, basically you could specify it's location:

"left side argument" 
|> A.a("first argument", _, "last argument")

---

I'm probably somewhat biased because I only used Elm before and there it's the last.

Let me know (anyone) your ideas and preference :)

[hazon]

I guess a better approach would be to introduce a second operator <| like Elm does.
Using the placeholder, as you suggest, could also be a viable option, however it would be confusing if you wanted to use partial application of a function... where you might have multiple _ params that you wanted to inject later on.

[itsgreggreg]

Piping as it exists in mint, elixir, elm, haskell, et all is not function composition rather application. |> ( & in haskell) is called "reverse application" and <| ($ in haskell) is regular old function application with a high precedence so you don't have to use parentheses.

Haskell, elm, reason, purescript, F# are all MLs, and have ML style syntax and term reduction.
Their type signatures look like:
|> : a -> (a -> b) -> b
<| : (a -> b) -> a -> b

Elixir is much different. Elixir is not an ML, does not perform term reduction like an ML, and its pipe operator is implemented as an AST rearranging Macro: https://github.com/elixir-lang/elixir/blob/v1.11.3/lib/elixir/lib/kernel.ex#L3665

Function composition on the other hand is where you take two functions, we'll call them an outer and an inner, and produce a new function that when given an argument first applies it to the outter function, then applies the result of that to the inner function. In elm there are two operators for this << and >>, in haskell there is the . that is equivalent to elm's <<.

Their type signatures look like this:

<< : (a -> b) -> (c -> a) -> (c -> b)
>> : (a -> b) -> (b -> c) -> (a -> c)

Why bring this up?
Because it highlights why |> behaves the way it does in those languages. Mainly that they are just functions that conform to the normal ML term reduction rules. There's nothing magical going on here other than perhaps things being allowed to be infix. In any case it's not a particularly fair comparison unless mint fancies itself an ML.

Thoughts on ergonomics:
Despite the conceptual simplicity of ML style, I find elixir's to be more ergonomic. Namely because piped and unpiped usage of a function feels consistent. For example Bitwise.rightShift (https://www.mint-lang.com/packages/itsgreggreg/mint-bitwise/0.5.0/modules/Bitwise#rightShift) Takes the number you want to shift as the 2nd parameter specifically so it works well with pipes. 9 |> Bitwise.rightShift(2) Means 9 >> 2, intuitive. But outside of pipes you'd call the function Bitwise.rightShift(2, 9) which once again means 9 >> 2, but no longer intuitive. I find this to be a bummer with elm and haskell, and would prefer them to be syntactic rewrites over function application.

Thoughts on _:
I'm a big fan. Gleam has syntax for this that creates an anonymous function of arity 1 wrapping the function call that uses the _. It looks like:

// https://gleam.run/book/tour/functions.html
pub fn run() {
  // This is the same as add(add(add(1, 3), 6), 9)
  1
  |> add(_, 3)
  |> add(_, 6)
  |> add(_, 9)
}

but you could also:

subtract_2_later = subtract(_, 2)

It's lovely to work with.

[gdotdesign]

Elixir is much different. Elixir is not an ML, does not perform term reduction like an ML, and its pipe operator is implemented as an AST rearranging Macro: elixir-lang/elixir@v1.11.3/lib/elixir/lib/kernel.ex#L3665

It's the same thing in Mint but without macros https://github.com/mint-lang/mint/blob/master/src/ast/pipe.cr#L13 it just takes the left hand side as the arguments and creates a call using the expression.

In any case it's not a particularly fair comparison unless mint fancies itself an ML.

I don't think Mint will every be treated as ML since it does much more.

Despite the conceptual simplicity of ML style, I find elixir's to be more ergonomic. Namely because piped and unpiped usage of a function feels consistent. For example Bitwise.rightShift (mint-lang.com/packages/itsgreggreg/mint-bitwise/0.5.0/modules/Bitwise#rightShift) Takes the number you want to shift as the 2nd parameter specifically so it works well with pipes. 9 |> Bitwise.rightShift(2) Means 9 >> 2, intuitive. But outside of pipes you'd call the function Bitwise.rightShift(2, 9) which once again means 9 >> 2, but no longer intuitive. I find this to be a bummer with elm and haskell, and would prefer them to be syntactic rewrites over function application.

This is a pretty good insight 🙏 I've never used a language where it puts it as a first parameter so I don't have the experience, maybe I should try it to get a feel for it.

[Sija]

Implemented in #571 🎉