Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-19 Thread Nathan Hüsken
On 12/18/2012 10:52 PM, Heinrich Apfelmus wrote: Nathan Hüsken wrote: On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote: Fair enough, but I don't see how this can be fitted into a general pattern. If the animation state is coupled tightly to the game logic state, then the question whether the

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-19 Thread serialhex
hey all, i've been lurking in this thread for a bit i just found this interesting article from chris granger (yeah, the light table guy). he just completed the node knockout they had recently decided to make a game. he did it all in clojurescript he discusses some aspects of programming a

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-18 Thread Heinrich Apfelmus
Nathan Hüsken wrote: On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote: Fair enough, but I don't see how this can be fitted into a general pattern. If the animation state is coupled tightly to the game logic state, then the question whether the animation is part of the game logic or not does not

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-12 Thread Nathan Hüsken
On 12/12/2012 01:26 AM, Ertugrul Söylemez wrote: Nathan Hüsken nathan.hues...@posteo.de wrote: Actually it is very scalable, as the same map is passed to every object. It can even live in the underlying monad, which means that you could even use a mutable vector, if you wish; however, I

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-11 Thread Nathan Hüsken
Am 10.12.2012 16:56, schrieb Ertugrul Söylemez: Nathan Hüsken nathan.hues...@posteo.de wrote: I put a pseudo C++ example below the mail. I use the terms model and view for the game logic and rendering respectively. The example is a little different. Asteroids explode when they collide. The

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-11 Thread Ertugrul Söylemez
Nathan Hüsken nathan.hues...@posteo.de wrote: Actually it is very scalable, as the same map is passed to every object. It can even live in the underlying monad, which means that you could even use a mutable vector, if you wish; however, I don't recommend that. Remember that a map is

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-10 Thread Nathan Hüsken
On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote: Nathan Hüsken wrote: Heinrich Apfelmus wrote: In that light, the separation seems straightforward to me. Given the time-varying values that represent game objects, bSpaceShipPosition :: Behavior Position bAsteroidPositions :: Behavior

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-10 Thread Ertugrul Söylemez
Nathan Hüsken nathan.hues...@posteo.de wrote: I put a pseudo C++ example below the mail. I use the terms model and view for the game logic and rendering respectively. The example is a little different. Asteroids explode when they collide. The moment asteroids explode, they are removed from

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-08 Thread Heinrich Apfelmus
Nathan Hüsken wrote: Heinrich Apfelmus wrote: In that light, the separation seems straightforward to me. Given the time-varying values that represent game objects, bSpaceShipPosition :: Behavior Position bAsteroidPositions :: Behavior [Position] bTime :: Behavior Time

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-12-06 Thread Nathan Hüsken
Sorry for the late reply, I somehow missed this eMail ... On 11/29/2012 06:28 PM, Heinrich Apfelmus wrote: If I take for example the breakout game from here [1]. It outputs an object scene of type Picture. But this picture is calculated from the objects ballPos and paddlePos. So first a game

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-11-29 Thread Heinrich Apfelmus
Nathan Hüsken wrote: Heinrich Apfelmus wrote: Personally, I would recommend is a complete change in perspective. The main idea of FRP is that it is a method to describe the evolution of values in time. What is a game? It's just a picture that evolves in time. The user can exert influence on

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-11-27 Thread Nathan Hüsken
On 11/27/2012 07:12 AM, Ertugrul Söylemez wrote: Nathan Hüsken nathan.hues...@posteo.de wrote: When writing games in other (imperative) languages, I like to separate the game logic from the rendering. For this I use something similar to the observer pattern. [...] So I am wondering: Is

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-11-27 Thread Ertugrul Söylemez
Nathan Hüsken nathan.hues...@posteo.de wrote: In fact it could be a (free) monad: myApp :: MyWire a (GameDelta ()) someDelta :: GameDelta () someDelta = do randomPos - liftA2 (,) getRandom getRandom replicateM_ 4 (addCreature randomPos)

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-11-27 Thread Heinrich Apfelmus
Nathan Hüsken wrote: Hey, When writing games in other (imperative) languages, I like to separate the game logic from the rendering. For this I use something similar to the observer pattern. With rendering I mean anything only related to how objects are drawn to the screen. Animation state for

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-11-27 Thread Nathan Hüsken
On 11/27/2012 04:18 PM, Heinrich Apfelmus wrote: Nathan Hüsken wrote: Hey, When writing games in other (imperative) languages, I like to separate the game logic from the rendering. For this I use something similar to the observer pattern. With rendering I mean anything only related to how

Re: [Haskell-cafe] Observer pattern in haskell FRP

2012-11-26 Thread Тимур Амиров
Not sure, but maybe you can define a Drawable class with a method in converting inner state to something draw func could use, so it would be like this: draw :: Drawable a = a - IO () вторник, 27 ноября 2012 г. пользователь Nathan Hüsken писал: Hey, When writing games in other (imperative)

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Neil Brown
Andy Gimblett wrote: Hi all, I've been doing some GUI programming recently, using wx. To help manage dependencies between state and UI elements, I looked for a Haskell version of the Observer design pattern, and I found an implementation written by Bastiaan Heeren of ou.nl [1]. Now,

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Eduard Sergeev
Andy Gimblett-2 wrote: To help manage dependencies between state and UI elements, I looked for a Haskell version of the Observer design pattern Isn't Reactive Programming approach more suitable than Observer if we talk about Haskell? -- View this message in context:

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Andy Gimblett
Hi Neil, On 9 Nov 2009, at 14:50, Neil Brown wrote: 1. Does anyone have any comments, on either version? There is no way to remove an observer, which is something I'd expect to have available. I realise this would require assigning a key to each observer (and thus perhaps storing them in

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Andy Gimblett
On 9 Nov 2009, at 15:21, Eduard Sergeev wrote: Andy Gimblett-2 wrote: To help manage dependencies between state and UI elements, I looked for a Haskell version of the Observer design pattern Isn't Reactive Programming approach more suitable than Observer if we talk about Haskell?

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Eduard Sergeev
Andy Gimblett-2 wrote: Possibly. Care to expand? If you have a more elegant solution, which fits in well with ordinary wxHaskell, I'd be interested. I believe there are a few experimental frameworks built on top of wxHaskell which use Functional Reactive Programming, like

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Andy Gimblett
On 9 Nov 2009, at 16:47, Eduard Sergeev wrote: Andy Gimblett-2 wrote: Possibly. Care to expand? If you have a more elegant solution, which fits in well with ordinary wxHaskell, I'd be interested. I believe there are a few experimental frameworks built on top of wxHaskell which use

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Neil Brown
Andy Gimblett wrote: was a bit surprised at first that the observers were called synchronously. Asynchronous is what I'd expect, and it's also harder to code the asynchronous handlers wrongly. One blocking call (such as putMVar) in a synchronous handler can screw up your whole program by

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Andy Gimblett
On 9 Nov 2009, at 17:41, Neil Brown wrote: Just to clarify -- I meant access to another MVar. Basically, if I do this: do v - newMVar addObserver sub (putMVar v) If when the observers are run, the MVar v (that I've allocated) is non-empty, my code will block until it is empty, which

Re: [Haskell-cafe] Observer pattern in Haskell?

2009-11-09 Thread Tom Lokhorst
I haven't looked at the code extensively, I just wanted to comment on this point: There is no way to remove an observer, which is something I'd expect to have available. I realise this would require assigning a key to each observer (and thus perhaps storing them in an associative map) or some