[Haskell-cafe] Interactive

Jonathan Cast 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.

jcc




More information about the Haskell-Cafe mailing list