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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
