[reactive] switching events = space leak?

[John Lato]

Hello,


> From: Don Vincenze <don at tr80.com>
>
> Hi,
>
> Is this list still alive ...
>
> I am trying to learn the theory of FRP by reading the code of this
> "reactive" library and Yampa. Not trying to get anything to actually
> work here, analyzing implementations of the theory only serve to assess
> the viability of it all. I.e. apart from bugs, is it stable, does it
> scale?
>
> For starters I'm worried about space leaks in switching events, e.g. see
> the "Event of Events" that's the input to switchE. Those events are
> lists that get produced by input producers but not consumed until
> they're being switched into, is that right? So during this time of
> producing but not consuming the list just grows = there is a space leak?
>

This can be a serious issue, however most modern FRP implementations (by
which I mean at least reactive-banana, elerea, and sodium) have solutions.
 I'm sure elm does as well, but I don't have experience with it.

I'm aware of two general approaches.  The first, used by elerea and sodium,
enforces that the creation of signaling and switching constructs happen
within a monad.  In this case the switching primitive looks something like

mSwitch :: Behavior (SGen a) -> SGen (Behavior a)

this function is responsible for ensuring that signals and behaviors are
represented in the monad, and thus executed.

The other approach was introduced in Grapefruit, and to my knowledge is
only used in Grapefruit and reactive-banana.  Instead of a signal
generation monad, switchable constructs have an extra type parameter that's
used to enforce aging.  apfelmus has written a bit about it at
http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-switching-0-7.html.
 Conceptually it's very similar to how the "st" parameter is used in
the
ST monad if you're familiar with that.

as to scaling, it is possible for a reactive network to scale to fairly
large systems, but not all of them do.  I've been meaning to blog about
this soon, maybe over the next week or two.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/reactive/attachments/20130206/cca47314/attachment.htm>