[feature request] currying support

[goodcucumber]

I noticed an expample of pipe in the doc

x |> f(y) // 等价于 f(x, y)

Looks like moonbit has currying and if I have a functiong fn f(x:Int, y:Int)->Int, then let g = f(2) makes g a function that takes one Int and output a Int, and g(3) is equal to f(3,2). But moon reports an error on it "This function has type (Int, Int) -> Int, which requires 2 arguments, but is given 1 arguments."

I think adding currying to moon makes x |> f(y) syntax more reasonable.

By the way, it is a bit strange that x |> f(y) is equivalent to f(x,y) not f(y,x). In my opinion, it is OK to make it a feature that parameters are pushed from right to left (so that in f(y) takes y as the second parameter), but then type of a function fn (x:Int, y:Float)->Float maybe better to have type (Float, Int)->Float of Float -> Int -> Float instead of (Int, Float)->Float.

[Yoorkin]

Looks like moonbit has currying

Currently, MoonBit does not support currying. x |> f(y) is treated as a whole, which is syntactic sugar for f(x, y).

We originally wanted to implement the pipe syntax similar to the Hack style pipe, where x |> f(y) would be a shorthand for x |> f($, y), which does not require currying support. However, we do not have placeholder syntax and are not sure if it will be introduced in the future. Perhaps it would be better to first to hear the community's feedback.

By the way, it is a bit strange that x |> f(y) is equivalent to f(x,y) not f(y,x).

The reason it is f(x, y) instead of f(y, x) is that MoonBit's API follows a "data first" design. This means that the data being operated on is placed at the beginning of the parameter list rather than at the end, which helps with type inference and provides useful completions in IDE.

For example, given let data = [1, 2, 3], if you are writing fold(data, init=0, fn(x, acc) { x.operation(acc) }) to process this array, the code is written from left to right: first the data, then the callback function. While editing the code inside the callback function, the type of data can be inferred from the earlier part, allowing the IDE to provide useful completions for x..

[bnyu]

However, we do not have placeholder syntax and are not sure if it will be introduced in the future. Perhaps it would be better to first to hear the community's feedback.x |> f(y)``x |> f($, y)

I prefer x |> f($, y) or x |> f(_, y) for the pipeline placeholder syntax

fn init {
  debug(3.14 |> Double::to_int) // output: 3
  debug(4 |> Array::make($, 'c')) // output: ['c', 'c', 'c', 'c']
  debug('c' |> Array::make(4, $)) // output: ['c', 'c', 'c', 'c']
}

[bnyu]

maybe x |> f(_, y) is better, I saw _ placeholder is used for function default argument

[bobzhang]

the pipeline syntax was discussed, we would not change the current design unless new compelling reasons proposed