2010/4/25 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?
I don't have a vertex buffers or texture in my update loop. These are low level details, left to the render loop. Indeed I maintained a pure information block in the update. If you really wanted to have low-level access in the update loop, I wouldn't know how to do that, although keeping two copies could work. Now my experiments were really simple 2D games, so not really state of the art.
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.
Yes, I see it more in the line of "profile based optimization", where a compiler performs static optimization based on a previous profile. I kind of abandoned the FRP thing because Haskell just feels a bit too complicated/abstract for me. It might also be that for the average person to learn Haskell really well, one needs a mentor. I would love to follow courses about it actually :)