Currying vs Partial Application

柯里化相当于函数重构；

偏函数相当于函数适配。

So, what is the difference between currying and partial application? As we stated before:

• Currying: Ability to decompose a function with arity N (where N is > 1) in a chain of calls to smaller functions with arity 1.
• Partial application: Possibility to apply a function with a given set of arguments to reduce the original function arity. A requirement to do partial application is that the function is already curried so that we can apply arguments one by one.

https://dzone.com/articles/functional-programming-functions

Currying

Currying is the process of taking a function that accepts Narguments and turning it into a chained series of N functions each taking 1 argument.

If we had an add() function that accepted 3 arguments and returned the sum,

we can turn it into a curried function as follows:

How does currying work? It works by nesting functions for each possible argument, using the natural closure created by the nested functions to retain access to each of the successive arguments.

What we want is a way to easily convert an existing function that takes Narguments into its curried version without having to write-out each curried version of a function as we did with curriedAdd().

Let's see if we can decompose this and build something useful.

Writing a generic curry()

Ideally, this is the curry() function interface we'd like to design:

Our curry() returns a new function that allows us to call it with one or more arguments, which it will then partially apply; up until it receives the last argument (based on the original function's arity) at which point it will return the evaluation of invoking the original function with all the arguments.

We know we can access the arity of a function using the .length property of the function. We can use this knowledge to allow us to know how many chained sequences of that function we need to call.

And, we'll need to store the original function passed in as well, so that once we have all the required arguments we can call the original function with the proper arguments and return its results.

Here's our first attempt:

Let's break this down in detail...

• line 2 our curry function returns a new function, in this case a named function expression called curried().
• line 3 every time this function is called, we store the arguments passed to it in args
• line 4 if the number of arguments is equal to the arity of the original function, we have them all, so
• line 5 return the invocation of the original function with all the arguments
• line 6 otherwise, return a function that will accept more arguments that, when called, will call our curried function again with the original arguments passed previously combined with the arguments passed to the newly returned function.

Let's give this a try with our original add function from before.

Excellent! This seems to do exactly what we want it to do. However, suppose we had an object with functions that depended on the proper object being set to the calling context (this) of the function. Can we use our curry function to curry an object method?

Uh oh. That's not what we wanted.

Using our curry() function as a method decorator¹ seems to break the object context expected by the method. We'll have to retain the original context and be sure and pass it along to successive calls to the returned curried function.

Let's try it again.

Got it! Now our curry() function is context aware and can be used in any number of situations as a function decorator.

Currying Variadic Functions?

So our current solution works and correctly retains the context when called, as long as those functions being curried only accept exactly the number of arguments they declare - no more, no less. This doesn't help us if we want to curry a function that has optional declared arguments or a variable number of arguments (variadic functions).

With variable argument functions, we need a way to tell our curry() function when it has enough arguments to evaluate the original function that it's currying.

Take the following functions

In the above, if we tried to use curry(max)(1)(2)(3) it evaluates too soon and we get a TypeError.

If we try to use curry(range)(1)(10) it never evaluates and simply stops by returning us a function that is still expecting another argument.

There is no feasible implementation of curry which will suffice for the example of our max() function which can take any number of arguments. Without an arity or a minimum number of arguments, there's no efficient way to determine when we should evaluate the original function with the arguments up to that point.

However, we can try to handle the case of optional, trailing arguments as in our range() example; and with minimal changes to our original curry()implementation.

We can modify our original curry() function to take an optional second argument which is the minimum number of arguments to curry.

Now, we can call curry(range, 2)(1)(10) as well as curry(range, 2)(1)(10,2). Unfortunately, though, we can't call it as curry(range, 2)(1)(10)(2), because as soon as it sees the minimum number of arguments, 2 in this case, it will return the results of evaluating the curried function.

What to do about Currying then?

It's clear from our examination above that currying in Javascript is definitely possible and useful. However, because Javascript allows any function to be variadic by nature, it becomes inefficient to implement a curry() function that can handle all possible cases.

Solution: If you're writing in a functional style, with unary and/or binary functions; and those functions take specific arguments that are declared, take advantage of currying. Otherwise, using our original implementation of curry() with the understanding that there are limitations surrounding functions with optional or variable arguments might be the best approach.

Partial Application

That was a lot of talking about currying; so, what is partial application?

Partial application means taking a function and paritallyapplying it to one or more of its arguments, but not all, creating a new function in the process.

Javascript already lets you do this with Function.prototype.bind()

But, that sounds a lot like what our curry() function does internally. If you have curry(), you also have partial application!²

The primary difference is in how you use them. We can implement a partial application function fairly easily (this is applying arguments from left to right)

And we can call this, much like bind but without the initial context argument, like var add6 = apply(add3, 2, 4).

ES6 curry and apply implementations

To wrap things up, I promised to cover the ES6 implementations as well, so here is curry(),

and here's our apply() function in ES6 as well.

The ...(spread/gather) operator and => fat arrow functions simplify the amount of code we need to implement our previous ES5 versions of curry and apply; and, I think they make the implementation more clear and understandable as well.³

You can find more references on this topic from these great posts as well.

https://www.datchley.name/currying-vs-partial-application/