> I heard complaints about this two-layered solution with
> SignalMonad/SignalGen, so I'm glad you like it. :)
Doesn't SignalGen replace SignalMonad in the experimental branch ? They
aren't meant to be used together, are they?
> By the way, I strongly recommend using the Experimental branch instead of
the current one
Yes, I just looked at FRP.Elerea.Experimental.Simple.
I have one question: in the stable branch, 'superstep' takes an amount of
time. In the experimental branch, it and 'createSignal' are replaced by
'start', if I'm right. So you do:
main = do
updater <- start gen
forever (join $ updater)
But there is no notion of time, here. So how do I make sure the network is
updated with the right amount of time?
2010/5/17 Patai Gergely <patai_gerg...@fastmail.fm>
> > 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
