[Haskell-cafe] Yampa vs. Reactive

[Thomas Davie]

Hi Henrik,

On 19 Dec 2008, at 02:05, Henrik Nilsson wrote:

> Hi Tom,
>
> > I'm not sure why mapping the function is not satisfactory -- It  
> would
> > create a new Behavior, who's internals contain only the two elements
> > from the list -- that would expose to the garbage collector that the
> > second element has no reference from this behavior any more, and  
> thus
> > the whole behavior could be collected.
>
> We must be talking at cross purposes here: there is no way that
> deleting the *output* from one of the behaviours from a list
> of outputs would cause the underlying behavior whose output no longer
> is observed to be garbage collected. After all, that list of
> three numbers is just a normal value: why should removing one of
> its elements, so to speak, affect the producer of the list?
>
> But if we have a list of running behaviors or signals, and that list
> is changed, then yes, of course we get the desired behavior (this
> is what Yampa does).
>
> So maybe that's what you mean?

I'm afraid not, rereading what I said, I really didn't explain what I  
was talking about well.  A Behavior in reactive is not just a  
continuous function of time.  It is a series of steps, each of which  
carries a function of time.  One such behavior might look like this:

(+5) -> 5 , (+6) -> 10 , integral

That is to say, this behavior starts off being a function that adds 5  
to the current time.  At 5 seconds, it steps, and the value changes to  
a function that adds 6 to time.  At this point, the function that adds  
5 to time can be garbage collected, along with the step.  At 10  
seconds, it becomes the integral of time, and the (+6) function, along  
with the next step is GCed.

To come back to your example, I'd expect the behavior to look like  
this (using named functions only so that I can refer to them):
i1 t = integral t
i2 t = integral (2 * t)
i3 t = integral (3 * t)
f t = [i1 t, i2 t, i3 t)]
g t = [i1 t, i3 t]
f -> 2, g

After 2 seconds, both f, and the first step may be garbage collected.   
As g does not have any reference to i2 t, it too can be garbage  
collected.

I hope that answers you more clearly.

> > That's a yes.  My first answer to how to implement the resetting
> > counter would be someting along the lines of this, but I'm not  
> certain > it's dead right:
> >
> > e = (1+) <$ mouseClick
> > e' = (const 0) <$ <some event>
> > b = accumB 0 (e `mappend` e')
> >
> > i.e. b is the behavior got by adding 1 every time the mouse click
> > event occurs, but resetting to 0 whenever <some event> occurs.
>
> Hmm. Looks somewhat complicated to me.
>
> Anyway, it doesn't really answer the fundamental question: how
> does one start a behavior/signal function at a particular point in  
> time?

In reactive, one doesn't.  All behaviors and events have the same  
absolute 0 value for time.

One can however simulate such a behavior, by using a `switcher`, or  
accumB.  In practice, having potentially large numbers of behaviors  
running but not changing until a certain event is hit is not a major  
problem.  This is not a problem because reactive knows that the  
current step contains a constant value, not a "real" function of time,  
because of this, no changes are pushed, and no work is done, until the  
event hits.

I believe Conal is however working on semantics for relative time  
based behaviors/events though.

Thanks

Tom Davie