I think trying make traditional computer games in functional languages is using the wrong tool for the job, the author reached the same conclusion.
Thats not to say that games aren't possible, they just need to be different kinds of games that are grown from the strengths of functional languages.
There's also: http://landoflisp.com/
1. The author has had second thoughts about his original conclusions: http://prog21.dadgum.com/37.html
2. The author is constrained by the Erlang feature set. The author rejects out of hand the idea of using "structs", but Clojure's maps and records are easy to use, share data and would perform admirably.
3. The author is constrained by his retrogame and microsystem domain. No modern gaming platform has issues with game state using too much memory or generating too much garbage (exception: complex physics). In fact, data duplication is now a common game performance technique. But if your tastes run toward ultralean programming, this is a distasteful state of affairs.
4. Much of modern game development has moved to an increasingly functional dataflow model already because of the necessities of multiprocessing and network gaming. It's rarely elegant and never done in a functional language, but it's the current reality.
5. Games are one of the places where a sophisticated view of time, as Rich Hickey advocates in his fantastic JVM Languages Summit keynote, offers a lot of value. It's a problem that thoughtful programmers and designers in the game industry have often considered, but have been unable to innovate much in the current technological regime. I just rewatched the talk last week, in fact, and highly recommend it for game programmers who read Hacker News:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
Actually, Clojure would be a great host for a library that makes deriving a valid and consistent state from multiple observations in the past, something every networked game needs to do, more regular and predictable. That's often one of those "scary" parts of a game's code base. Things get pretty hairy, there is a lot of ad-hoc code, bugs are hard to track down and nobody wants to mess with it so it tends to get even cruftier and scarier.
I suspect that Haskell's monads are a solution. Can someone with Haskell experience attest to this?
So each simulation step takes you from W + I => W' which you hand off to the pre-renderer and the next simulation step. The pre-renderer will combine the game world state with static data (i.e. models and shaders) and produce game-state-free data that a renderer can display to the user.
This is the basic framework I've used for twelve years when I've been able to implement it (i.e. not often at my day job). It's worked really well, but I actually have not applied it in a language that supports purely functional programming. So you can guess why I'm in this thread.