Currying RFC

[iopq]

Automatic currying of all functions and closures

[huonw]

There's no need for 'heavy closure return types', e.g. just writing |b| add(1, b) works.

[iopq]

if I return |b| add(1, b) from my function I will have to declare the function's return type to be -> |int| -> int

if add is implemented that its return type is Vec<Rc<Cell<int>>> then the return type of the function when curried is |Vec<Rc<Cell<int>>>| -> Vec<Rc<Cell<int>>>

[huonw]

I think there's basically two reasons one would explicitly return a closure:

1. to make currying easier
2. to be able to cache some work that can be reused repeatedly later

The first is (slightly verbosely) replaced by writing |b| add(1, b) at the call site, and automatic currying is not really a replacement for the second.

To replace 2, the compiler would have to do some form of partial evaluation/partial application, which I imagine would be quite difficult to do in a reliable manner in Rust, i.e. if it actually mattered for performance a human would probably do the partial application transformation manually anyway.

[huonw]

This isn't very detailed. It should at least vaguely the discuss the mechanics of 'turned into a closure', I would imagine that unboxed closures with by-value captures come into play and are worth mentioning, as would exhibiting some code transformations into explicit closure form, e.g. foo(a, b)(c, d); becoming (|x, y| foo(a, b, x, y))(c, d).

Also, what about efficiently handling static vs. dynamic function calls? i.e. let f: Box<FnTrait> = if ... { some_2_arg_closure } else { some_other_2_arg_closure }; let g = f(1); g(2) would presumably need to capture f into the g closure somehow, but would it capture by-value or by-reference? (Sometimes it will need to be by-value, e.g. when currying a FnOnce closure, sometimes it will need to be by-reference, since it is possible to continuing using f later.)

But, then, it would be inefficient (at compile time) to actually capture the function into a closure for static function calls (like calling add(1, 2) above); this would bloat our IR significantly and slow LLVM to a creep (this is an implementation detail but it'd be nice to mention it, since compile times are very user-visible).

Lastly, what about more interesting curries:

• methods
• overloaded call operator (this definitely needs discussing since it is how unboxed closures work)

[huonw]

Also, what does foo() do? For uniformity, it 'should' just return a closure around foo, since, if foo takes n args, it's passing 0 out of n, and thus should return a closure taking n args itself. The worst part is when n == 0.

[iopq]

No, because when you reach the 0 argument case it just executes. 0 is the base case, you execute until you reach it. As I understand it, in Haskell getChar doesn't curry just because it has no arguments. It just executes and reads from standard in.

If I write main = getChar it won't ask for more arguments. It will just execute getChar.

[huonw]

getChar is not a zero-argument function, (from the outside) it's just a value representing an IO action, that can be executed by being sequenced in main.

Anyway, as I said above 0 is not "logically" the base case, especially not for a closure taking at least one argument, e.g. let f = |a| { ... }; f().

[huonw]

Another drawback is likely making error messages slightly more confusing, e.g. missing an argument now is:

fn add(x: int, y: int) -> int { x + y } 

fn main() {
    let z = add(1) * 2; // error: this function takes 2 parameters but 1 parameter was supplied
    println!("{}", z);
}

but under this RFC it would (naively) become something like "type |int| -> int does not implement Mul". (This should either be a drawback or a plan to avoid these problems should be mentioned above. Investigating how e.g. Haskell handles might be a good idea.)

[dobkeratops]

Another drawback is likely making error messages slightly more confusing,

^ could the context be used to guess a bit: if you're passing an expression to a function argument, assume the user wants to curry. Anywhere else, give a warning about missing parameters first "add takes 2 parameters; curried to |int|->int"

[huonw]

Yes, we could infer/guess; but it needs to be written down, because it's very important.

[SimonSapin]

-1. Explicit currying would be nice (either through a macro or custom syntax), but I think that implicit currying is too much magic.

[dobkeratops]

how about allowing arity-based overloads ,enabling the community to implement currying or default parameter macros , and see how it fits in the language in widespread use

[killercup]

I too would like to see currying done explicitly (let square = power(_, 2)).

First, because explicit is better than implicit (and simple is better than complex), and second, because then it would be almost orthogonal to parameters being named and/or optional.

In my ideal world, it would be possible to say let completed = reduce(_, callback = |acc, x| { acc + 1 }, acc = 0), where completed will be called with a _ that is required to implement reduce (and the reduce call above will actually be akin to Uniform Function Call Syntax, i.e. calling _'s reduce method: completed(user_list) == user_list.reduce(callback, acc)).

[lilyball]

-1 as well. I like the idea of explicit currying though.

[liigo]

prefer explicit
Sent using CloudMagic
On 周三, 8月 06, 2014 at 5:33 上午, Kevin Ballard notifications@github.com wrote:-1 as well. I like the idea of explicit currying though.

—Reply to this email directly or view it on GitHub.

[pnkfelix]

I'm obviously biased, but I'll just point out that I think the way this RFC handles call-sites would conflict with my proposal for auto-tupling at call-sites: http://discuss.rust-lang.org/t/pre-rfc-auto-tupling-at-call-sites/175

(although maybe a sufficiently clever programmer could use the auto-tupling proposal to implement calls to a curried function.)

[dobkeratops]

suggestion for the OP: maybe separate the discussion of keyword arguments and defaults - mention in 'alternatives' or 'drawbacks' the option of currying being mutually exclusive with 'trailing defaults', also the suggestion of explicit sugar to disambiguate either.

also r.e. 'functions vs methods' - you could suggest only currying free-functions initially, to avoid issues about what people expect 'self' should do. One could always wrap a free function around some method-dispatch

this RFC handles call-sites would conflict with my proposal for auto-tupling at call-sites:

could it still co-exist - this auto-tippling is what to do when you supply more arguments, whereas currying (and even defaults) deal with passing fewer arguments. You could simply say that the variadic arguments are never curried.
IMO currying,defaults, and variadic/auto-tupling would all suit different situations.

[lilyball]

FWIW, it should be possible to write a curry!(power(_, 2)) syntax extension. Heck, you could probably even write a bind!(power($2, $1)) extension that would let you reorder arguments (similar to C++'s std::bind), although using nonterminal tokens like that (if it even parses them with digits, I'm not sure) might possibly have issues if you're embedding a macro call (though hopefully not, as you'd replace all of them before the embedded macro is evaluated). Or you could do something like bind!(power(_2, _1)) which is a bit more reminiscent of the placeholders used by C++.

[bgamari]

@kballard in my opinion you the succinctness of Scala's explicit currying is its primary draw. Introducing a curried call with a macro negates most of this advantage.

[dobkeratops]

in my opinion you the succinctness of Scala's explicit currying is its primary draw. Introducing a curried call with a macro negates most of this advantage.

+1. as soon as you wrap it in a macro.. you might aswell just write a closure.. its just a prefix |x,y| vs bind!(...) the closure might even be fewer characters already

[lilyball]

The macro approach has the benefit of letting you reorder arguments. I like the power(_, 2) syntax though, which doesn't support reordering but is also concise.

[Drup]

The nice thing about the syntax power(_, 2) is that it's compatible with both labeled and optional arguments (It was discussed a bit here).

[nikomatsakis]

Thank you for the suggestion. During the triage meeting today, we decided to close this RFC. As @huonw points out, there are numerous issues that would have to be addressed to flesh out the proposal, but even more than that I think there is a general feeling that automatic currying is not something we plan to add to Rust.