
On Tue, 2008-11-25 at 18:43 +0000, Andrew Coppin wrote:
Thomas DuBuisson wrote:
Here are the links that hold the information you desire: http://www.haskell.org/haskellwiki/Frag http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf http://www.cse.unsw.edu.au/%7Epls/thesis/munc-thesis.pdf
In short: FRP http://www.haskell.org/frp/
On Wed, Nov 12, 2008 at 1:52 PM, Andrew Coppin
mailto:andrewcoppin@btinternet.com> wrote: I have a small question...
Given that interactivity is Really Hard to do in Haskell, and that mutable state is to be strongly avoided, how come Frag exists? (I.e., how did they successfully solve these problems?)
Having read the paper [again], I'm still don't understand a word of it. So I'm still wondering how Frag actually works.
OOP seems like such a natural fit for describing the behaviour of a network of independent objects. But Haskell seems to require you to make a new, modified copy of the entire game state at each frame,
Small note: this depends on the data structure. Some structures allow for large amounts of state sharing; in particular, the old copy of any object that didn't change can probably be re-used. I don't know how much that applies to Frag, but I've found it to be quite helpful performance-wise in the past. And, in general, most of the interest in FRP isn't in making functions over time work --- that's easy --- but in minimizing re-computation, which includes precisely re-using earlier results when possible. jcc