[Haskell-cafe] ANN: Elerea, another FRP library

[Patai Gergely]

> 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