[Haskell-cafe] Implementing PacMan
andrewcoppin at btinternet.com
Wed Dec 17 16:41:46 EST 2008
Ryan Ingram wrote:
> Oops, misread a bit. I thought this was your series of posts, Andrew!
> But other than that, my points stand :)
Don't you just *hate* it when you reply, and then later realise you
missed some small but important detail? ;-)
As for your actual content... I will have to meditate deeply on this to
comprehend if/why it's helpful here. (As with all good ideas!)
> On Wed, Dec 17, 2008 at 12:13 AM, Ryan Ingram <ryani.spam at gmail.com> wrote:
>> In the last "episode" you talk about an entity's update being a function like:
>>> input_state -> (output_state, [event])
>> for some suitably defined types of input state, output state, and event.
>> Connecting together functions with types like this is exactly what
>> Reactive does well. You have an event stream representing the
>> behavior of the user during the course of the game, and you use that
>> to construct other values representing the *behavior* of the game.
>> The key difference is that instead of the game's behavior being a set
>> of functions from input to output, it is functions from one behavior
>> to another, eventually culminating in something like
>>> -- "user input", "clock tick"; output a new display list at each clock tick
>>> game :: Event UserInput -> Event () -> Reactive [RenderCommand]
>> In fact, I think your analysis in the first message is somewhat right
>> on; this exercise is somewhat like "writing a novel without using the
>> letter 'e'". The benefits you get from a pure language are not
>> necessarily "lack of effects", but rather, "explicitly mentioning
>> where effects happen".
>> That said, I'm curious where you are going with it. I'd love to see
>> the game running & take a look at your code!
>> -- ryan
More information about the Haskell-Cafe