22 November 2009

Micah 6:8

A popular verse from today’s Sunday school lesson in a lesser known form:

But he’s already made it plain how to live, what to do, what God is looking for in men and women. It’s quite simple: Do what is fair and just to your neighbor, be compassionate and loyal in your love, and don’t take yourself too seriously—take God seriously.

—Micah 6:8 (The Message)

12 November 2009

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]) {
} else {
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.

05 November 2009

Pogue says call them “app phones”

In Call It an ‘App Phone’ (A What?), David Pogue suggests “iPhone-like” devices should be called “app phones”. (The link in to nytimes.com, so you either have to register to read it.)

Calling it a “phone” at all seems silly to me. The phone is just one feature and not the most important one.

These are palmtop computers. “PDA” would fit; I just never liked that term.