Addendum to function currying

In my last post I’ve tried to explain the differences between partial function application and function currying.

The post was more generally addressed to JavaScript developers (as an accompanying material to a presentation I’m working on) so I’ve tried to keep the text as practical as possible in the context of JavaScript programming.

But as I remarked on, the post wasn’t academically correct, more precisely the examples I’ve used had a specific purpose of incorrectness. Skipping that part for now, let’s just see what exactly currying means to its true definition.

In mathematics and computer science, currying is the technique of transforming a function that takes multiple arguments (or an n-tuple of arguments) in such a way that it can be called as a chain of one argument functions.


If we where true to that definition, a function add(a, b, c, d) in a curried form would actually be representable in JavaScript under the following form:

Now, for a second let’s suppose that we could actually curry a function to that form. As far as I was able to reason and do, the only possible variant was a curry function with on-demand currying.

I’ve tried my best with that one without succumbing to tempting human sacrifice. Some javascripters with knowledge in JavaScript’s darker arts may enlighten me on a better implementation; I have no doubts in such a thing.

Anyway let’s see that curry function in action:

While an interesting hack, it’s far away from being a curry function. In fact, there is no single curry function in any JavaScript library, no matter how functional it calls itself. Search for curry in these libraries documentation here, where the author is even nice enough to offer an explication:

Note that, unlike in languages with true partial application such as Haskell, curry and uncurry are not inverses. This is a cause to the fact that in JavaScript, unlike Haskell, a fully saturated function is not equivalent to the value that it returns. The definition of curry here matches semantics that most people have used when implementing curry for procedural languages.

And you could pick the Prototype documentation, or the one for underscore and you’d get the similarity between them and the one in my earlier article; but they are still not the currying function.

Anyway, what I’m trying to go at, their role in JavaScript serves as partial application functions; that being the basis of my previous post, where in spite of incorrectness, I wanted to make it clear that there is difference between the two that is not generally very clear to new developers (without functional programming knowledge, that is).

In the voice of a great man, Live long and prosper


Currying definition: http://en.wikipedia.org/wiki/Currying
Functional javascript library documentation: http://osteele.com/sources/javascript/functional/
Prototype function curry documentation: http://api.prototypejs.org/language/Function/prototype/curry/
Underscore function bind documentation: http://documentcloud.github.com/underscore/#bind


Filed under Code, Discussion

  • Ryan O’Hara

    I might do it this way:

    function curry(f){
    if(!f.length) {
    return f;
    }

    var args = [];

    var c = function() {
    for(var i = 0; i = f.length) {
    return f.apply(null, args);
    } else {
    return c;
    }
    };

    return c;
    }

    Haven’t tested that, but it should work. f.length, not f.toString()! :)

    • http://activedeveloper.info mhitza

      Definitely better.

      I was tempted at one point at looking if there is a way to get the number of arguments of a function, but I suppose I got carried away and wrote that .toString() hack :)