And just as IO is unnecessary for behavior (functions of time), it's also unnecessary for imagery (functions of space). Continuing with the functional (non-IO) theme, you can give a semantically precise, composable and simple type of images. Yes, that's a further separation of concerns. Instead of producing an IO action, you produce a data structure to be consumed by the framework. However, there's an interesting question of dealing with feedbacks, i.e. signals affected (or even created and destroyed) by the IO actions resulting from your output. It might sound like too low-level design if you have to rely on IO-bound feedback, but I don't see how it could be put behind a nice abstraction in general. For instance, if you have some large terrain to roam around, you'll have to keep most of it on the disk (static as well as dynamic objects), and it depends on your location and orientation which parts get loaded and discarded/archived at any time. While low-level caching and loading of resources is certainly not the responsibility of the reactive subsystem, it will still have to manage the life cycle of signals. And that's what I'm missing: a nice way to describe this kind of feedback. Grapefruit looks like a possible solution to this problem (assuming it can be made completely dynamic), and then the integration of a Grapefruit-like and a Reactive-like system could be the ultimate solution in the long run.
Gergely -- http://www.fastmail.fm - IMAP accessible web-mail