I looked at elerea. I found it simple and nice! I heard complaints about this two-layered solution with SignalMonad/SignalGen, so I'm glad you like it. :)
I just regret the fact that the SignalMonad can only be run inside IO. That's life. ;) However, there is only a single point where you have to do the conversion, and you can think of everything as a pure abstraction within that top-level SignalGen. By the way, I strongly recommend using the Experimental branch instead of the current one, because sampler (the 'almost join') breaks referential transparency and generally behaves badly if you have more than two Signal layers to break down, which can easily happen in practice. Also, the new stuff is much more efficient.
With reactive, you can transform signals in pure code. Sure, but you'll need IO anyway if you want to hook up the signals to peripherals. Both libraries allow you to describe the combinations of reactive values in a pure way, but they inevitably have to face the RealWorld at some point...
Yes, as no optimization is done? But as long as you compile the code, you don't have such a problem? No, it's not a matter of optimisation, it's an intrinsic problem. Optimisation just makes it less obvious. I don't know how bad it is in practice though, because the more entities are created, the more often garbage collection should kick in, so it might not hinder scaling as much as one would think. You can also look at the bounce example in the elerea-examples package if you want a minimal test case for dynamic
collections.
Does reactive work elsewise? Yes. If you don't need a reactive value in Reactive, it is not evaluated. This means that unreferenced values just sit in memory until
they are swept up by the garbage collector, as you would expect. This policy has a different unpleasant consequence though: if a stateful reactive value (e.g. our favourite integral) is only requested long after its start time -- which is always the start time of the whole program in the case of Reactive --, all its past has to be kept in memory, and the first evaluation will potentially take a lot of time while the computation is catching up. So it will cause a different kind of space-time leak than Elerea. Grapefruit has an interesting solution to this problem that uses phantom types to keep track of the observers of a signal. Elerea just forces every live signal to be updated to prevent big thunks from building up.
I know that every FRP framework will have its own hiccups, as it is a domain which is still in development, but still, I found the time-leak bug (if it is a bug) in reactive very weird. I still haven't managed to find out whether it's just an implementation issue or somehow the consequence of the basic design of the library. Hopefully the former. The run-time behaviour of Reactive is quite complex, so it's difficult to pinpoint the source of the problem.
Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own