Functional JavaScript, Part 4: Function Currying (tech.pro)

I was thinking about whipping together a perfJS for the curry function and putting it in the post but ended up not... I might make one and post it back here.

---

UPDATE: I made this jsperf: http://jsperf.com/curry-function

There might be better things to test, but the results were actually unexpected. Currying "manually" with nested functions is actually slower than using my "curry" function.

As I mentioned in my post, if you are touching the DOM at all, I really doubt you will see much of a performance hit from using this...

Unless you're in tight loops you wont notice this perf hit. Disk, Network, and DOM manipulation will be the 99% time sinks.

Me too. I thought long and hard about how I could use functional programming (aside from the usual callbacks) and came to the conclusion that functional programming is more composable - that's its strength - how you can combine stages in a pipeline. It's all centered around data flow instead of execution flow.

One example would be jQuery or Underscore - how you can chain operations with the "." operator, or another common example is how we use the pipe " | " operator in the shell to compose processes. I use the latter quite a lot and am proficient at making pipelines.

By contrast, procedural programming relies a lot on global variables and that makes a mess of reusing pieces of code from an app into another.

This is very interesting. I'm not so sure this wouldn't trip me up some times though. What if the first argument you are expecting, is supposed to be a function? I would think that would be a pretty common scenario...

Unless I'm not quite getting what you mean?

EDIT: I see that this would only happen if you passed in more arguments than expected, thus it wouldn't be a problem.

Very cool! I might update mine to work this way.

    // Pass 3 values to a curried function which just-so-happens to return
    // other functions
    curry(function(w, x) {
      return function(y) {
        return function(z) {
          return w + x + y + z;
        };
      };
    })(1, 2, 3, 4);

    // Take the first 2 arguments to be w and x
    (function(w, x) {
      return function(y) {
        return function(z) {
          return w + x + y + z;
        };
      };
    })(1, 2)(3, 4);

    // Apply the first function
    (function(y) {
      return function(z) {
        return 1 + 2 + y + z;
      };
    })(3, 4);

    // The above version will ignore 4 and wait for another z.
    // This is why we need to uncurry it.
    uncurry(function(y) {
      return function(z) {
        return 1 + 2 + y + z;
      };
    })(3, 4);

    // Now we can execute it properly
    (function(y) {
      return function(z) {
        return 1 + 2 + y + z;
      };
    })(3)(4);

    (function(z) {
      return 1 + 2 + 3 + z;
    })(4);

    10;

> I could never justify using this stuff at work. It's ... unfamiliar to most JS developers and even if it did pass a peer review, nobody else would actually want to maintain it.

The same could be said for any API.

Currying is actually very unobtrusive; the only time a curried function behaves differently to its uncurried counterpart is when it's given a 'wrong' number of arguments. The benefit is never having to perform manual eta-expansion (ie. any time we write a redundant wrapper like "function(x) { return bar(a, b, c, x); }").

As for efficiency, I default to having the machines doing things to save developer's time and only do things the other way around when it's untenable (or for fun).

@platz, yes, this is correct. When currying and/or composing functions, it becomes more difficult to determine the input/output types of the function since the function signature won't be right there. I'm borrowing the `//+` syntax from Brian Lansdorf, since I saw him use it and quite like it. He mentioned he has "a lot to say on the topic" of commenting / type sigs, but I haven't heard him speak specifically on that.

Also, for functions that do different things depending on how many arguments are passed in, you would never want to curry these. The curry function relies on the function passed in expecting a specific number of arguments.

As it exists in Haskell, yes, that's what partial application is — the result of applying a curried function to less than the full number of arguments. Some other languages have a more general form of partial application where you can partially apply arguments in non-sequential order, which isn't related to currying and instead just means creating a wrapper function that calls the original function with certain arguments filled in.

I assume you mean "partial application"?

"Currying" turns a multi-argument function into a chain of one-at-a-time wrappers. If we curry a 5-argument function "foo(a, b, c, d, e)", we get a nesting of 5 functions, each accepting one argument "foo(a)(b)(c)(d)(e)". The implementation in the article, as well as my own, go slightly further and also allow curried functions to accept multiple arguments at once, eg. "foo(a, b, c, d, e)"; this is just for convenience though, a "real" curried function must accept arguments one at a time. Note that in Haskell syntax, there is no difference between the two: "foo a b c d e".

Alternatively, "partial application" takes some argument values now, returning a function which accepts the rest later. If we partially-apply a 5-argument function with, say, its first 2 arguments, we get back a 3-argument function, eg. "papply(foo, a, b)(c, d, e)".

Note that we must use partial application explicitly whenever we want to supply a few more arguments; curried functions keep track of this themselves.

As an aside, you mention Haskell. Note that Haskell functions are already curried; in Haskell, "curry" and "uncurry" convert between functions which accept separate arguments and functions which accept one big tuple of arguments.