2010/4/25 Patai Gergely <patai_gerg...@fastmail.fm>: >> (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 :) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
