[reactive] switching events = space leak?

[John Lato]

elerea itself doesn't follow the event/behavior distinction, so it looks
quite a bit different from the others.  Also it doesn't have a particular
switch combinator, rather switching behavior is enabled by the use of
recursive-do bindings.

I think reactive-banana's approach is expressive enough to do as you
suggest, but I haven't actually tried it yet.

I'd also be interested in a language-agnostic forum for FRP issues.

John L


From: Don Vincenze <don at tr80.com>
>
> Wow thank you for all these pointers ... I must take the time to look
> into these libraries. Stuff like this doesn't come up when you Google
> "Functional Reactive Programming" or at least doesn't rank very high.
>
>
>
> I'm not sure I understand the sodium approach (couldn't find switch in
> elerea). The aging/'trimming' approach in banana seems to rely on the
> events being switched into being known from the start, i.e. the point
> in time 'switch' starts executing. This way you can dynamically switch
> into a static set of events but not dynamically into a dynamic set of
> events.
>
>
>
> In any case, considering such concerns seem to be transcend individual
> libraries/frameworks, you wouldn't know of any mailing list/forum that
> is more suitable for this discussion, i.e. a general FRP forum not tied
> to any library or one purely focused on theory?
>
>
>
>
>
> On Wed, Feb 6, 2013, at 07:22 PM, John Lato wrote:
>
>
> 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 [1]http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-swi
> tching-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.
>
> References
>
> 1.
> http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-switching-0-7.html
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/reactive/attachments/20130207/d4748a02/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Reactive mailing list
> Reactive at haskell.org
> http://www.haskell.org/mailman/listinfo/reactive
>
>
> End of Reactive Digest, Vol 18, Issue 3
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/reactive/attachments/20130208/8f85b6d4/attachment.htm>