Partially Applied Functions In JavaScript

I’m finding myself doing more and more functional programming with JavaScript lately – especially in recent days with this WinJS project I’m working on, and the heavy use of promises that it encourages. This feels a little odd to me, considering my current passion for building object-oriented JavaScript apps with Backbone. But at the same time, there’s something very natural about a functional style in JavaScript. There are a lot of fun things you can do with a functional style in JavaScript and I encourage you to explore it.

Partial Function Application

One of the tools that I’ve picked up in the process of exploring a functional style is partial function application, which according to Wikipedia, allows us to provide “a number of arguments to a function, producing another function of smaller arity.” (“Arity” is a fancy word for argument count of a function). Note that partial function application is not the same thing as “currying”. The two ideas may be similar, but they are definitely different and the two terms should not be interchanged.

What partial function application really means is that we can take a function that expects 2 parameters, and create a partially applied function that has the first parameter fixed. The result is itself a function that expects only one parameter. When calling that last function, the result of the original function is produced.

An example:

Here, we’re using the ECMAScript 5 standard of the “bind” function to do the partial application. The “bind” function serves two purposes: 1) to bind a function’s context (“this” argument) and 2) to create a partially applied function.

The net result, when calling the “partial” function, is what you would expect to get by calling the original function with two parameters. This can be used any number of times, across any number of parameters. You can supply one or more arguments to bind to your partially applied function, and you can partially apply a partially applied function as well. Of course, this might get a little ridiculous after a while, but it can still be done.

Implementing Partial Application

The most basic way to get partial application in to your code is to write for browsers and runtimes (like NodeJS and WinRT) that support ECMAScript-5.

(Side note: Since I’m working with WinJS and WinRT in a Windows 8 runtime, I get to stick with raw ECMAScript 5 in my JavaScript. IE10 does a great job of implementing this standard, and it’s really a pleasure to write applications for this browser and the WinRT run time. The added benefit of not having to worry about cross-browser compatibility when building a WinJS application is also really refreshing.)

But even if you’re not using a browser or runtime that supports ECMAScript-5 standards and the “bind” function, partial application is easy to do. Writing a function to do it yourself doesn’t take much effort, and there are plenty of implementations available to use – like this one from John Resig:

Now you might not want to go and modify the core JavaScript “Function” prototype to add this (I wouldn’t personally). But don’t worry, you could easily modify that to work as a separate function call on it’s own. Or, you could use a library like Underscore.js, which provides partial application via the “bind” function on itself instead of modifying the Function prototype:

There are probably a thousand other implementations of this around. I’m only listing these two for the sake of brevity in this blog post.

A Use Case For This

I’ve known about partial function application for quite some time now. But I’ve never had a reason to use it and never understood why it would be useful, or in what scenarios it might be a good idea. It just seemed like an academic exercise to me. In the WinJS/WinRT app that I’m building with the MS P&P group, though, I may have found a scenario where it makes sense and creates a much more clean expression of code than not using it.

This is some code that @bennage and I wrote for the sample WinJS/WinRT app that we’re building:

It’s not terribly bad. In fact, it’s quite terse and easy to read. It makes heavy use of promises and chains them together. Each of the function calls returns a promise, which facilitates the chained “then” calls. Except there’s that one call in the middle where an inline function is provided in order to get a second parameter passed to the function via a closure. I wanted to see what it would take to make this inline function go away, and partial application solved that problem for me:

In this version, the inline function has been removed and a local variable has been provided in it’s place. That local variable is a partially applied function, using ECMAScript-5’s “bind” function. I apply the first parameter to the actual function call, and that returns a function that now only needs one parameter. Since the parameter that comes from the “then” call in the promise chain is the exact parameter that this partially applied function needs, I can supply this partially applied function to the “then” call and everything works as expected.

No, Really. An Actual Use Case For This?

Ok, this is a pretty trivial example and can easily be argued as unnecessary. The original code wasn’t that bad and may be easier to understand for some people. But the end result of the chained “then” statements has a certain beauty and elegance that I love. It’s got a distinct functional style and flow that makes it very easy for me to read, as if I’m looking at a sequence diagram for my code – and I can’t help but love that.