[Haskell-cafe] Implementing PacMan

[Andrew Coppin]

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