The problem with Javascript’s map

This is about Javascript programming. If you’re not interested in Javascript programming, bail now.

Say you have a Javascript array of strings that you want to convert to numbers.

['1', '2', '3'].map(parseInt) ⇒ [1, NaN, NaN]

Hmm. Why didn’t that work? Because parseInt takes an optional parameter (the radix)...

parseInt('ff', 16) ⇒ 255
parseInt('2', 1) ⇒ NaN // Because a radix of 1 always returns NaN
parseInt('3', 2) ⇒ NaN // Because 3 isn’t a valid binary digit

...and map passes an optional second parameter (the index).

[1, 2, 3].map(function(n, i) [n, i]) ⇒ [[1, 0], [2, 1], [3, 2]]

Occasionally it is very handy to have map give you that index. Often, however, I want to give map a function—like parseInt—that wasn’t explicitly designed to be used with map.

Here’s how to fix it.

['1', '2', '3'].map(function(_){return parseInt(_);});

Yuck. Not only is that verbose, it looks downright silly since the closure looks pointless.

Expression closures can address the verbosity...

array.map(function(_) parseInt(_));

..., but (currently) only Firefox versions 3.0 and later support that. Plus, it still obscures why you’re doing it.

In Scheme, I’d use cute from SRFI 26. It allows you to specify some parameters of a function. The “<>” is used for parameters that you don’t want to specify.

(map (cute string->number <> 10) '("1" "2" "3"))

Of course, while string->number takes an optional radix parameter like parseInt, Scheme’s map doesn’t pass the index, so this isn’t necessary.

Back to Javascript. A “unaryize” function looks nicer than an explicit closure and makes what you’re doing clearer.

function unaryize(f) {
return function(_) {
return f(_);
}
}

['1', '2', '3'].map(unaryize(parseInt)) ⇒ [1, 2, 3]

We could generalize unaryize to naryize.

function naryize(f, n) {
return function() {
return f.apply(null,
Array.prototype.slice.call(arguments, 0, n));
}
}

['1', '2', '3'].map(naryize(parseInt, 1)) ⇒ [1, 2, 3]

In practice, I’ve run into uses of unaryize several times, but I haven’t yet run into a need for naryize. Also, naryize is less efficient than unaryize.

What if we want to specify a radix? We could create a Javascript version of cute. I’ll use undefined instead of “<>” for the slot specifier.

function cute() {
var cutargs = Array.slice(arguments);
var f = cutargs.shift();
return function() {
var args = Array.slice(arguments);
var fargs = [];
var i;
for(i = 0; i < cutargs.length; ++i) {
if(undefined === cutargs[i]) {
fargs.push(args.shift());
} else {
fargs.push(cutargs[i]);
}
}
return f.apply(null, fargs);
};
}

['a', 'b', 'c'].map(cute(parseInt, undefined, 16)) ⇒ [10, 11, 12]

Again, I haven’t yet run into many cases where I’d want to use cute that unaryize doesn’t suffice. In this specific case, I think I’m happy with the explicit closure.

['a', 'b', 'c'].map(function(_){return parseInt(_, 16);});

Additional notes:

Array.map can be implemented in Javascript and added without any changes to the interpreter. I’m using Prototype’s.

Expression closures can’t be added without changes to the interpreter, but they can be faked with strings. See Functional Javascript

While cute can be implemented as a function, SRFI-26’s cut has to be a macro. Likewise, a cute macro is more efficient than the procedure implementation.