
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?)

On Wed, 12 Nov 2008, Andrew Coppin 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?)
Because the givens are bull :-) That said, Frag doesn't throw too many different types of entities around and its performance isn't great when you look at the game simulation (largely because it was an experiment in using FRP). -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage.

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
In short: FRP
http://www.haskell.org/frp/
On Wed, Nov 12, 2008 at 1:52 PM, Andrew Coppin
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?)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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, which sounds... highly non-performant. What am I not seeing?

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

Hello Andrew, Tuesday, November 25, 2008, 9:43:11 PM, you wrote:
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, which sounds... highly non-performant.
"most of the game state" is a few mb maximum. you don't need to copy textures and other permanent game object descriptors which occupies most part of those hundredths mbs just an example from my own work: i wrote an archiver which may use, say, 500 mb for storing list of million files. but the list itslef occupies only ~10mb, so i can do all the forms of complex processing without over-loading memory manager. each file descrption is 500 bytes long, but this info isn't changed during program run -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (5)
-
Andrew Coppin
-
Bulat Ziganshin
-
Jonathan Cast
-
Philippa Cowderoy
-
Thomas DuBuisson