jonathanccast at fastmail.fm
Tue Nov 25 13:48:51 EST 2008
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
> > <andrewcoppin at btinternet.com <mailto:andrewcoppin at 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.
More information about the Haskell-Cafe