[Haskell-cafe] [reactive] A pong and integrate

[Patai Gergely]

> 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