Comments on: Simply efficient functional reactivity (original) (raw)

For (2), yes. I found it very interesting that given the interface to future could be that minimal (four small typeclasses & two or three additional operations) and all of the “definition”-side of behavior/reactive/event could be specified in terms of that minimal interface.

Of course you need to plumb into the implementation details when you are writing the interpretation functions (occs/sinkE/sinkR), unless you take waitFor and force as primitive as well, which severely constrains the design of Future. But most client code can absolutely ignore that and use the behavior/reactive/event abstraction.

(3) From your definition of mappend on events:

u mergeu v = (inFutR (merge v) <$> u) <+> (inFutR (u merge) <$> v) where inFutR f (r Stepper Ev u0) = r Stepper Ev (f u0)

Consider the case where v = never. The rhs of <+> goes away, but we still call “merge” in the lhs, and pass v again. So any storage held by v cannot be reclaimed, and there’s also a time leak as <+> keeps getting called needlessly.

The more merges that happen, the worse the leak gets.

]]>