Parsed Participle

As someone who has maintained his set of 'dotfiles' faithfully for a few years now, window-manager choice and configuration has been of great importance. I used FVWM for a few years, finally switching to Sawfish somewhere in 2005. My sawfish configuration mimics what I had set up in my fvwm days rather closely, and sporadic periods of messing around with settings have been the only (enjoyable) disruption to my otherwise very productive computing life (as far as my Desktop environment is concerned).

I switched to Sawfish simply because it's scripting language, librep is a Lisp - one that I had been spending many commuting Zaurus hours on. Life has been very good with this the way it is.

Until I read yesterday's LTU article a post that talks about side-effects in imperative languages that cause closures to capture variables in less-than-desirable ways. It was not the actual post itself, but a link to a series, with one interesting post featuring a tour of Haskell and a rather fabulous example to use as a working demo program: XMonad, a really good window manager written in and extensible in Haskell:

• Windows are automatically tiled
• Mouseless
• Configurable (even in real time), using Haskell

I'm tempted to try it; given todays large displays, arranging windows with your mouse just feels silly.

Imperative-style Iterations and closures don't mix well

The undesirable form of variable capture that Erik Meijer describes is, I think, a lot to do with supporting closures in languages where C-style iteration is still relatively a norm. The for (i = 0; i<10; i++){ /*..*/ } lets you use the i as a block scope variable while it remains a part of the mechanism of the iteration. It's easy to reproduce this in Perl (the language which is many things to many people), if you use the C iteration idiom:

my @arr = ();
for (my $i = 4; $i < 7; $i++) {
    push @arr, sub {
        return $i;
    };
}

for (my $i = 4; $i < @arr; $i++) {
    my $f = $arr[$i];
    print $f->(), "\n";
}

But the idiomatic way does away with this problem; and things are better now that we don't have to get distracted by the iteration mechanism: map and grep where one can:

my @arr = map {
    my $i = $_;
    sub {
        return $i;
    }
} (4..7);

print $_->(), "\n" foreach @arr;

Javascript may not have map/grep, but for Functional-style iterations, libraries do a great job of providing such utilities. Prototype.js comes to mind.

var delayedActions = [4,5,6,7].map(function (n) {
    return function (i) {
        return i;
    };
});

In fact this is where these closure-ish APIs shine - they overcome Javascript's problem (i.e., variables only have function scope) by expressing loops functionally.