Self-”partially applying” JavaScript functions

6 Feb, 2008  AS3, JavaScript

Was: self-currying JavaScript functions

I read this nice post on self-currying JavaScript functions, and even though the code to me is not optimal (dispite the low line count), it is improperly named, and it depends on the Prototype JavaScript library (which I really don’t like), it is a very nice script and a very nice idea. The trick in this script is using Function.prototype.length. I didn’t know that this property existed, but after digging a bit I’ve realized, that it has been in ECMAScript at least since 3rd edition (which is the latest edition published in 1999), in JavaScript since v1.1, but only made it into ActionScript by ActionScript 3 (which I haven’t study in as much detail as I have with ActionScript 1 and 2 in relation to my book on basic programming in these versions).

In this post I discuss this property and functionality a bit further, and I implement this function for creating self-”partially applying” functions using both no framework, the MochiKit framework and the Prototype framework.

Background

So, what is this property? I have not seen anyone use it before, not in production nor in any of the major JavaScript libraries. It might have been in use by a lot of people several times, but I just haven’t come across it. It has the simple function of returning the number of named arguments, that a given function is originally created with. The function will be called and might work just fine given less or more parameters, but Function.prototype.length is the number of named arguments in the definition. The ECMAScript language specification is kind of vague on the functionality, as it uses the term “usually”:

The value of the length property is usually an integer that indicates the “typical” number of arguments expected by the function. However, the language permits the function to be invoked with some other number of arguments. The behaviour of a function when invoked on a number of arguments other than the number specified by its length property depends on the function. […]

In his post James Coglan uses this property to create what he originally denotes as self-currying functions, but agrees with a commenter, that it is in fact self-”partially applied” functions using the proper terms. I would though go to the extend to say, that the functions are neither curried nor partially applied – their application/evaluation/invocation is just postponed until the correct amount of parameters have been accumulated. If the function was partially applied, the partially applied function would run faster (in theory), as it has been specialized with respect to the already supplied parameters, but this is not the case. The parameters are simply stored until the number of parameters given (potentially across several calls) matches the number of arguments “typically” accepted by the original function.

One of the issues about the implementation by James Coglan that caught my eye, is the use of the prototype chain. Many have an opinion about whether to contaminate the prototype chain or not, but I am of the latter school and really dislike this. Contaminating the global namespace (i.e. window) is thus the only other alternative, but for this a single global object containing all library functions can be created. This is the approach that my preferred library, MochiKit, uses but Prototype (which is way more popular than MochiKit) extends built-in JavaScript objects using the prototype chain. I have thus decided to implement this functionality both in native JavaScript and using MochiKit or Prototype methodologies. Another minor issue with the implementation by Coglan is the use of the activation object to read variables from the inner function. This tends to leak memory (as collected by Quirksmode here), so the general rule of thumb here is to store such values on the function instance and retrieve them from arguments.callee.

In native JavaScript

First the implementation in native JavaScript. Note the two helper functions, of which the first is needed, as arguments isn’t a real array, and the latter is the general “curry” or “partial” method found in most libraries:

JAVASCRIPT:
  1. function makeArray(a) {
  2.   for (var b = [], i = 0; i < a.length; i++)
  3.     b.push(a[i]);
  4.   return b;
  5. }
  6. function bind(f, a) {
  7.   var g = function() {
  8.     var c = arguments.callee;
  9.     return c._func.apply(
  10.       null,
  11.       c._args.concat(makeArray(arguments))
  12.     );
  13.   }
  14.   g._func = f;
  15.   g._args = a ? makeArray(a) : [];
  16.   return g;
  17. }
  18. function partialize(f, n) {
  19.   var g = function() {
  20.     var c = arguments.callee;
  21.     if (c._len <= arguments.length)
  22.       return c._func.apply(null, arguments);
  23.     return bind(c, arguments);
  24.   }
  25.   g._len = n || f.length;
  26.   g._func = f;
  27.   return g;
  28. }

The above bind-function is not optimal, as re-binding creates an extra layer of function calls which could easily be avoided by reusing the values stored on the function instance, but for this use, the above suffices.

This function can the be utilized exactly like the one by Coglan – except that this partialize function is actually a function, where the toSelfCurrying function by Coglan is a method (available through any function instance):

JAVASCRIPT:
  1. var adder = function(a,b,c) {
  2.   return a + b + c;
  3. };
  4. var add = partialize(adder);
  5. add(1)(2)(3)  // --> 6
  6. add(7,8)(23)  // --> 38

In MochiKit

Implementing this in MochiKit and using the power of the built-in functions (especially bind), this becomes only the last function:

JAVASCRIPT:
  1. function partialize(f, n) {
  2.   var g = function() {
  3.     var c = arguments.callee;
  4.     if (c._len <= arguments.length)
  5.       return c._func.apply(null, arguments);
  6.     return MochiKit.Base.bind(c, arguments);
  7.   }
  8.   g._len = n || f.length;
  9.   g._func = f;
  10.   return g;
  11. }

If keeping with the MochiKit spirit, one would save this function in the MochiKit.Base library and globally if export is active:

JAVASCRIPT:
  1. (function(){
  2. // closure to avoid cluttering window
  3. function partialize(f, n) {
  4.   var g = function() {
  5.     var c = arguments.callee;
  6.     if (c._len <= arguments.length)
  7.       return c._func.apply(null, arguments);
  8.     return MochiKit.Base.bind(c, arguments);
  9.   }
  10.   g._len = n || f.length;
  11.   g._func = f;
  12.   return g;
  13. }
  14. // save in MochiKit.Base:
  15. MochiKit.Base.partialize = partialize;
  16. // if export is active, save on window:
  17. if (MochiKit.__export__) window.partialize = partialize;
  18. })();

In prototype

If you are using Prototype, you probably do not dislike the use of extending built-in classes using the prototype chain, thus the implementation is a slight change of the implementation by Coglan:

JAVASCRIPT:
  1. Function.prototype.toSelfCurrying = function(n) {
  2.   var g = function() {
  3.     var c = arguments.callee;
  4.     if (arguments.length >= c._len)
  5.       return c._func.apply(this, arguments);
  6.     return c.curry.apply(c, arguments);
  7.   };
  8.   g._len = n || this.length;
  9.   g._func = this;
  10.   return g;
  11. };

UPDATE: Fixing typo pointed out by James Coglan.

This is almost as compact and just as readable.

Vote Reddit Story ?

3 Comments so far »

  1. James Coglan said

    at February 7 2008 @ 01:06

    Quick typo fix: in your Prototype example, you need to call c.curry.apply() rather than method.curry.apply(), since ‘method’ is not defined in your version of my code.

    Interesting to see different approaches. I won’t get into a debate about global functions, but I should point out that use of closures do not cause memory leaks. Memory leaks tend to be caused by circular references between JavaScript objects and DOM objects — closures can make such references hard to spot, but they do not cause the leaks. This has nothing to do with the DOM, in fact I’ve just been running my method millions of times through Drip and it shows constant memory usage.

  2. James Coglan said

    at February 7 2008 @ 01:08

    Sorry, just realised my comment was ambiguous. By “This has nothing to do with the DOM”, I meant that partial function application (not memory leaks) has nothing to do with the DOM.

  3. Barklund said

    at February 7 2008 @ 10:42

    Hi James,

    I’ve fixed the typo, and regarding your comment on “to leak or not”, I have come to the habit of never using the activation object for variables that need be accessed inside inner functions. In this case, neither f nor n can be DOM objects agreed (as they are supposed to be a function and an integer respectively), but if I for the fun of it (and for the errors it will throw) invoke it with n set to some DOM object, that I remove from the DOM afterwards, we might get a leak quite easily (not tested though).

    Thus I have come to the habit of never using the activation object in such smaller helper functions, that are generalized to work on just about anything.

Comment RSS · TrackBack URI

Leave a comment

Name: (Required)

eMail: (Required)

Website:

Comment: