Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-05-03 Thread Edward Kmett
On Sun, May 2, 2010 at 6:23 PM, Ben midfi...@gmail.com wrote: hello -- i'm putting the finishing touches on a cabal package based on what felipe gave, i've managed to make it an arrow transformer which is nice. i have a few issues though. 1) i know it is not possible to add class

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-05-02 Thread Ben
: Re: [Haskell-cafe] Re: FRP for game programming / artifical       life    simulation To: haskell-cafe@haskell.org Message-ID: 20100429030922.ga7...@kira.casa Content-Type: text/plain; charset=us-ascii On Wed, Apr 28, 2010 at 04:16:08PM -0700, Ben wrote: so i tried state machines of a sort

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-30 Thread Antoine Latter
On Fri, Apr 30, 2010 at 3:37 AM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 29 April 2010 20:08:00 schrieb Ben: A technical question: it seems like the instance of ArrowLoop is too strict (this is something I've wondered about in Liu's paper too.) Shouldn't it be  instance

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-30 Thread Daniel Fischer
Am Freitag 30 April 2010 17:23:19 schrieb Antoine Latter: On Fri, Apr 30, 2010 at 3:37 AM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 29 April 2010 20:08:00 schrieb Ben: A technical question: it seems like the instance of ArrowLoop is too strict (this is something I've

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-30 Thread Ben
FYI i got the lazy pattern match from Patterson's Programming with Arrows, so I'm assuming it makes a difference. (I'll work out a real example later.) B On Fri, Apr 30, 2010 at 8:45 AM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Freitag 30 April 2010 17:23:19 schrieb Antoine Latter:

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Christopher Lane Hinson
On Wed, 28 Apr 2010, Ben wrote: thanks for the comments, i'll try to respond to them all. but to start off with, let me mention that my ultimate goal is to have a way of writing down causal and robust (restartable) computations which happen on infinite streams of data in a nice way -- by

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Ben
Peter -- Thanks for the pointers. Have you seen Uustalu T., Vene V. The Essence of Dataflow Programming ? Can't say I understand it all but it is a compelling picture. I do like the notion of distributive laws between monads and comonads. B On Wed, Apr 28, 2010 at 9:58 PM, Peter Gammie

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Ben
), s1) in (c, s2) or do I misunderstand lazy pattern matching? Best, B Date: Thu, 29 Apr 2010 00:09:22 -0300 From: Felipe Lessa felipe.le...@gmail.com Subject: Re: [Haskell-cafe] Re: FRP for game programming / artifical lifesimulation To: haskell-cafe@haskell.org

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Ben
Lane -- Thanks for the suggestion, I'll take a closer look shortly. At the moment I have to confess to not exactly understanding what your code is doing, it's a little hairy for me? Right now I'm going to focus on what Felipe has given me, it fits in nicely with the arrow framework, which I'm

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Daniel Fischer
Am Donnerstag 29 April 2010 20:08:00 schrieb Ben: A technical question: it seems like the instance of ArrowLoop is too strict (this is something I've wondered about in Liu's paper too.) Shouldn't it be  instance ArrowLoop SFAuto where      loop (SFAuto s f) = SFAuto s f'          where    

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Ben
Ah, thanks! b On Thu, Apr 29, 2010 at 11:37 AM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 29 April 2010 20:08:00 schrieb Ben: A technical question: it seems like the instance of ArrowLoop is too strict (this is something I've wondered about in Liu's paper too.) Shouldn't

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-29 Thread Christopher Lane Hinson
Basically, this is the differential equation hairball I mentioned earlier. You can define a set of Operators -- a modification of Mealy automata that accepts two inputs -- and any mapping of inputs to outputs within the Operation monad. The Operation monad uses an existentially quantified

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Ben
I want to save the state of the system to disk, I want to be able to play the game, pick a point to stop, freeze it and turn off the computer, and then come back later and resume. Why is that unwise? What are the alternatives? B On Tue, Apr 27, 2010 at 9:28 PM, Christopher Lane Hinson

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Christopher Lane Hinson
On Wed, 28 Apr 2010, Ben wrote: I want to save the state of the system to disk, I want to be able to play the game, pick a point to stop, freeze it and turn off the computer, and then come back later and resume. Why is that unwise? What are the alternatives? B On Tue, 27 Apr 2010, Ben

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Peter Verswyvelen
Interesting topic. I find it a bit annoying that Haskell doesn't provide support to save functions. I understand this is problematic, but it would be very nice if the Haskell runtime provided a way to serialize (part of) the heap, making sure that pointers to compiled functions get resolved

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Chris Eidhof
I agree. This would be an extremely useful feature, not only for game development, but also for web development. We often use continuations as a way to add state to the web, but this fails for two reasons: whenever the server restarts, or when we scale to multiple machines. However, I think it

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Gregory Crosswhite
On Apr 28, 2010, at 3:41 PM, Limestraël wrote: I think the problem with function serialization is that unlike languages which run over a virtual machine, bytecode generated by GHC is platform-specific (just as compilated C or C++) and therefore can run directly on top of the system, which

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Peter Verswyvelen
As a side note, it's interesting that C# doesn't allow serialization of closures (anonymous delegates). The compiler-generated name assigned to an anonymous delegate can be different after each re-compilation. This is also really annoying in C#/.NET, since one must explicitly add a named method if

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Christopher Lane Hinson
I think y'all are talking past each other, a little bit. There are two ways to serialize a function: 1) Serialize the bytecode for the function. 2) Serialize a persistant reference to a function that resides inside the executable. Personally, I think that either strategy is dubious. If you

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Ben
thanks for the comments, i'll try to respond to them all. but to start off with, let me mention that my ultimate goal is to have a way of writing down causal and robust (restartable) computations which happen on infinite streams of data in a nice way -- by which i mean the declarative /

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Felipe Lessa
On Wed, Apr 28, 2010 at 04:16:08PM -0700, Ben wrote: so i tried state machines of a sort newtype STAuto s a b = STAuto { unSTAuto : (a, s) - (b, s) } where the interruptibility would come from being able to save out the state s. i was not successful, unfortunately, in this level of

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Peter Gammie
Ben, On 29/04/2010, at 6:16 AM, Ben wrote: [...] newtype STAuto s a b = STAuto { unSTAuto : (a, s) - (b, s) } As Felipe observes in detail, this can be made to work. He uses Read and Show for serialisation, but clearly you can use whatever you like instead. I just wanted to add that one

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-27 Thread Christopher Lane Hinson
I'm not sure exactly what you want to do. It should certainly be easy to freeze an FRP program by lying about the amount of time that is passing and witholding all events. Do you want to save an FRP system instance to disk (generally unwise), or something else (what?). Friendly, --Lane On

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-26 Thread Peter Verswyvelen
2010/4/25 Patai Gergely patai_gerg...@fastmail.fm: (in my own FRP experiments I have an update thread and a render thread). I wonder how to nicely deal with state that requires communication with the outer world, even though it is functional at heart. For instance, if you want to change a

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-25 Thread Christopher Lane Hinson
1) In FRP, there is no global *type* GameState that stores the whole game state. Rather, the game state is implicit in the collection of active computations. This is also why state updating and drawing is woven together in FRP, which is good syntactically, but hard to disentangle for

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-25 Thread Peter Verswyvelen
Actually, I believe that many Yampa examples do separate the drawing from the update... The arrow provides the game data that *can* be rendered. If you provide interpolators for that game data, you can still achieve the same as is explained in fix your timesteps (in my own FRP experiments I have