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