[Haskell-cafe] Re: FRP for game programming / artifical life simulation

[Christopher Lane Hinson]

> 1) In FRP, there is no global *type*  GameState  that stores the whole
> game state. Rather, the game state is implicit in the collection of
> "active" computations. This is also why state updating and drawing is
> woven together in FRP, which is good syntactically, but hard to
> disentangle for interpolation.

I disagree somewhat with this.  FRP should be thought of like the IO 
monad, out of which everything that can be lifted, should be, especially 
the GameState.

I like to imagine that the FRP's job is to observe the GameState and 
reenact changes therein.  Some changes take a little while to act out, and 
the FRP element that is doing the action can signal that it isn't ready 
for the next transition.  Or, if no changes occur, the actors can stand 
around doing idle animations.

Friendly,
--Lane