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

[Patai Gergely]

> (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 vertex buffer or a texture or whatever during the
update, how do you organise your code? Do you maintain separate pure and
impure state information blocks?

> However, it is not clear if you want to "pull" or "push" such a network
>From what I've seen so far, I think you really need both at the same
time. Pull for continuous signals and push for events. The tricky part
is that events can be derived from signals (cf. Fran's predicate
events), and you really don't want the signals depending on these events
to be reevaluated even when there are no occurrences. The best you can
do with pull is to explicitly keep the previous output when there's no
incoming event. However, if you fmap over this output, the function will
be evaluated in every step regardless of the lack of change, since
functions are not memoised. I believe this is a problem Grapefruit aims
to solve with its notion of segmented signals [1].

Deciding between push and pull according to profiling results is a nice
idea. :) It might be too expensive to do it adaptively during runtime
(the overhead might easily distort the results and thus render them
invalid), but treating it as just a flag could give us an interesting
architecture to play with.

Gergely

[1]
http://hackage.haskell.org/packages/archive/grapefruit-frp/0.0.0.0/doc/html/FRP-Grapefruit-Signal-Segmented.html

-- 
http://www.fastmail.fm - A fast, anti-spam email service.