(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/... -- http://www.fastmail.fm - A fast, anti-spam email service.