*Alluded

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.

Yeah, I found some of that a little while back which definitely help a lot (before I switched to Linux as my primary OS…unrelated reasons), and the aspell thing is actually designed as a replacement for ispell on all platforms (Linux’s will quite often just symlink them).

The HOME trick is useful for working with the shell buffer as well, which doesn’t like spaces in the path (although cygwin itself doesn’t seem to care!?).

Either way, thanks for the input, hopefully it will help anyone reading this in the future.

– Lorenz

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.