Currying & Partial Application

Cooking functions with delicious computer science.

A lot of blogs posts have been written about partial application and currying. Unfortunately a lot of them get it wrong. There is a widespread misconception about what currying and partial application actually is and there are countless examples in all kinds of languages that are completely wrong. This post is going to set things straight with examples in JavaScript.

Partial Application

What is partial application? Wikipedia tells us pretty straightforward:

In computer science, partial application (or partial function application) refers to the process of fixing a number of arguments to a function, producing another function of smaller arity.

Arity just means the number of arguments that a function takes (un-ary, bin-ary, tern-ary, …). Doing it manually looks like this:

Here we are fixing a number of arguments (one argument which we called a is fixed to the value 1) to a function (the function add) producing another function (the function inc) of smaller arity (inc takes only one argument).

But we can do much better by using the functional powers of JavaScript and write it this way:

This is proper partial application now. When using underscore or lodash you can use the partial function which is much nicer than the raw bind method. And there is the handy partialRight function which fixes arguments starting from the right which is quite useful since underscore and lodash are doing it wrong.

Currying

Now that we understand partial application we can learn about currying. It is named after Haskell Curry. Wikipedia tells us:

In mathematics and computer science, currying is the technique of translating the evaluation of a function that takes multiple arguments (or a tuple of arguments) into evaluating a sequence of functions, each with a single argument (partial application).

That may seem convoluted but once you understand what it all means it’s actually pretty clear.

Consider a logging function that takes three arguments:

log(status, context, message)

If we were to manually write a curried version it would look like this:

Writing it this way has the benefit that we don’t need to use explicit partial application if we want to produce new functions by fixing further arguments. For example:

Currying is really just automating this manual process with the added convenience that we don’t have to use this weird butt-looking syntax if we supply more than one argument at once. Here is an example using the lodash curry function:

Comparison

If it’s still not quite clear what the difference between currying and partial application is maybe it will be clearer with the following example. Consider a variadic function, i.e. a function that takes any number of arguments, like the (s)printf string formatting functions for example.

function format(format, ...args) {
  // fancy formatting code here
}

We can’t really curry this function unless we fix its number of arguments but we can use partial application. For example:

Essentially the observable difference between currying and partial application is that a partially applied function will always delegate to the original function when it is called, a curried function only does so once all the arguments have been supplied. See this silly example for demonstration:

And now the curried version:

tl;dr

Currying is not partial application. It can be implemented using partial application. You can’t curry variadic functions (unless you fix the number of arguments, i.e. making it non-variadic).

Further Resources

• Professor Frisby’s mostly adequate guide to functional programming (great real-world examples using currying).
• Functional Programming Resources In JavaScript
• Brian Lonsdorf — Hey Underscore, You’re Doing It Wrong!