Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] currying support #299

Open
goodcucumber opened this issue Sep 10, 2024 · 3 comments
Open

[feature request] currying support #299

goodcucumber opened this issue Sep 10, 2024 · 3 comments

Comments

@goodcucumber
Copy link

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
Copy link
Collaborator

Yoorkin commented Sep 13, 2024

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
Copy link

bnyu commented Nov 19, 2024

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
Copy link

bnyu commented Nov 19, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants