So, that was a while ago… http://save-endo.cs.uu.nl/ is the website.
I participated in it with a bunch of friends, but we never managed a particularly good implementation of the basic spec. We were able to render the starting image – in something like 4 hours. Anyway, the thing opens up into a scavenger hunt, of sorts, and I got tantalizing glimpses of that hunt but our implementation never let us get anywhere. I’ve recently picked the thing up again, resulting in something that renders the starting image in about 3 minutes (so far). It’s on github: https://github.com/imccoy/icfp07
It’s the most non-trivial thing I’ve ever written in haskell. As it turned out, getting it working and correct was not particularly hard (incidentally, finger trees rock), but I have had a bugger of a time getting rid of the space leaks so that the thing could actually run to completion. That makes haskell an interesting contradiction, for me: I love the way it’s type system and purity conspire to prevent surprises, but I hate the way it’s laziness creates more surprises.
I imagine I’ll keep poking at it, both in terms of optimizing the implementation further and trying to find more of the stuff they’ve hidden away in there.
Fine Shambles 
Interesting. I pretty much completely agree. Laziness in Haskell is a wonderful thing in theory, but it should not be the default. It is a nifty trick, and that’s it. I think programmers need to at least be in control of the time and space complexity of their operations.
And it distracts us from the real advantages of Haskell: the aforementioned purity and type system (which have nothing to do with laziness, except that laziness requires purity — purity does not require laziness).