Reactive animations:
http://conal.net/fran/tutorial.htm

The above work set the corner stone of FRP.

The Yampa arcade:
http://www.haskell.org/yale/papers/haskell-workshop03/yampa-arcade.pdf

I think the Yampa arcade (and Yampa in general) are not quite functional as we’d like, but they are an interesting approach.

The idea of FRP is that pure functional values CAN be used to denote dynamic things.

When I get to the postmortem however, I fully intend to have another look at the FRP architecture.

Haskell Records Considered Grungy

As I understand it the IO types are “more or less” just renamed ST types anyway, allowing true IO (externally controlled side effects) to be separated from the pure functional core. Since real side effects which are type constrained so they don’t escape a block of code are, from the outside at least, still referentially transparent and therefore functional. But your right, as the code base grows, some guarantees about IO could become essential.

Right now I’m actually more concerned with the overhead involved in using monadic code like readIORef. Eventually I think I’ll learn the operations involved in combining this kind of code better, but for now I think it might be more useful just to get something working and go from there.

Heh, that tying the know thing reminds of a post that appeared on planet haskell a while back…Infinite loops in Haskell.

IOW to turn the game state into something like a relational database. It’s good for serialization e.g. one could implement save game via “deriving (Read)”, but slow for lookups. It fits the idea of expressions quite well and the flexibility is great but for a real game wouldn’t it be better if relationships were by pointer under the covers? I imagine one would create a datatype that lies on top of the expression oriented fkey style database, similar to a view in RDMS terms. As a n00b this hurts my head but it seems like I’m thinking in the right direction. “Tying the knot” appears to be required in the general case.

http://haskell.org/wikisnapshot/TyingTheKnot.html

There’s a common notion among outsiders and new Haskellers that Haskell “can’t handle something as complex as X.” This is absolutely true if you’re using the IO monad to do work that is not IO.

But later, as I worked with it, the big picture became clear. The idea in Haskell isn’t to eliminate IO. That’s impossible. A program made from pure functions is rarely useful. Instead, monads (and monad transformers) allow the programmer to put his or her own restrictions on how much of the outside world touches your program.

The first thing I’d do if I were writing any sort of complex game-looking program in Haskell would be to create a type to manage the state of your program: GameState. This type will be a monad and a member of MonadIO, to allow you give you access to the lovely Turing-based world on the other side of the void.

From there, you expose only the IO calls you need. If you need a timer in the game, then you provide for a function sleepMilli :: Int -> GameState (). But you probably don’t need general disk access for the game, so you hide openFile. The only time you’ll need to read and write files is for config files, maps, and saved games, but those simply become parameters for generating your game state object: loadGame :: String -> IO GameState, which takes the name of a save file and loads it.

Using a GameState object is also useful for maintaining mutable objects in your game. Replacing all the IORefs with STRefs or similar makes the guarantee Turing stays on the other side, while still providing you a ton of flexibility.

From there, all your generic algorithms: collision detections, state-based game AI, victory conditions are just functions of your game state.