Go Haskell! (was: [Haskell-cafe] What *not* to use Haskell for)

[Claus Reinke]

> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?

If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still around?-):

http://computer-go.org/pipermail/computer-go/2008-October/016680.html

The specification is the numbered list at the end of the message, or in the 
zip file with the Java example implementation (README). Actually, the 
interesting part from a performance perspective doesn't even require GTP 
or AMAF, just implement the random legal playouts for a 9x9 board, do 
a loop over them, keeping some basic win/loose/game length statistics.

Can you complete that in competitive speed, preferably from the specs,
without just transliterating the low-level Java code?  I won't tell you yet 
what typical playouts-per-second-per-core numbers are floating about 
for "lightly" optimised code; try to improve your code and say "stop, 
this is good enough" before comparing with the Java bot runtimes.

You'll probably have no room left for any high-level operations, ending 
up with mostly imperatively threaded array manipulations in a loop that 
is expected to be run several thousand times per real-game move (the 
idea being to run lots of dumb, but legal, simulations to the end, where 
evaluation is easy, gather statistics, then choose the move that seems 
to have the most potential). Bonus points if you can preserve any of the 
high-level advantages of working in Haskell (such as easy debuggability, 
because there will be bugs, especially if you can't afford to maintain 
redundant information representations) without sacrificing speed. (*)

As specified, the bot won't win any tournaments - it is the starting 
point (or remote ancestor) for the current champions, with lots of room 
for algorithmic improvement, not to mention actual game knowledge,
tree search and parallelization (the configurations being used for tournaments 
and exhibition games are highly parallel). The reference spec is a recent
effort, meant to provide a first milestone for aspiring Go programmers
to compare their code against, while also inviting programmers to
to show how their favourite language is eminently suitable for Go
programming (without sacrificing performance!). There are versions
in Java, D, C++, C#, and C around somewhere, possibly others.

But: please, no language evangelism on that mailing list! Those people
seem decent, peaceful and open-minded (there's even a Haskell spec
of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ).

And some of them have years (a few even decades) of experience,
much of which is made available in the mailinglist archives and
bibliography (pointers available on request - if you wanted to get
serious about playing with Go programming, you'd be expected
to mine the archives and bibliography, because just about anything
you'll come up with in your first few months will have been discussed
already;-), in spite of commercial interests and ongoing competitions.
They are already tired and wary of useless language wars (who isn't?).

Claus 
    (who has been wanting to write a Go player ever since he 
    had to decide between research and learning more Go, either 
    one trying to eat all available time and then some; perhaps I 
    should write a researcher instead, and return to playing Go?-)

(*) it would be nice if the sequential baseline performance of
    functional Haskell/Ghc arrays would be better, btw; that would
    make the ongoing work on parallel arrays much more interesting.