<div dir="ltr">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.<div>
<br></div><div style>I think reactive-banana's approach is expressive enough to do as you suggest, but I haven't actually tried it yet.</div><div style><br></div><div style>I'd also be interested in a language-agnostic forum for FRP issues.</div>
<div style><br></div><div style>John L</div><div><div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Don Vincenze <<a href="mailto:don@tr80.com">don@tr80.com</a>><br>
<br>
Wow thank you for all these pointers ... I must take the time to look<br>
into these libraries. Stuff like this doesn't come up when you Google<br>
"Functional Reactive Programming" or at least doesn't rank very high.<br>
<br>
<br>
<br>
I'm not sure I understand the sodium approach (couldn't find switch in<br>
elerea). The aging/'trimming' approach in banana seems to rely on the<br>
events being switched into being known from the start, i.e. the point<br>
in time 'switch' starts executing. This way you can dynamically switch<br>
into a static set of events but not dynamically into a dynamic set of<br>
events.<br>
<br>
<br>
<br>
In any case, considering such concerns seem to be transcend individual<br>
libraries/frameworks, you wouldn't know of any mailing list/forum that<br>
is more suitable for this discussion, i.e. a general FRP forum not tied<br>
to any library or one purely focused on theory?<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Feb 6, 2013, at 07:22 PM, John Lato wrote:<br>
<br>
<br>
This can be a serious issue, however most modern FRP implementations<br>
(by which I mean at least reactive-banana, elerea, and sodium) have<br>
solutions. I'm sure elm does as well, but I don't have experience with<br>
it.<br>
<br>
I'm aware of two general approaches. The first, used by elerea and<br>
sodium, enforces that the creation of signaling and switching<br>
constructs happen within a monad. In this case the switching primitive<br>
looks something like<br>
<br>
mSwitch :: Behavior (SGen a) -> SGen (Behavior a)<br>
<br>
this function is responsible for ensuring that signals and behaviors<br>
are represented in the monad, and thus executed.<br>
<br>
The other approach was introduced in Grapefruit, and to my knowledge is<br>
only used in Grapefruit and reactive-banana. Instead of a signal<br>
generation monad, switchable constructs have an extra type parameter<br>
that's used to enforce aging. apfelmus has written a bit about it<br>
at [1]<a href="http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-swi
tching-0-7.html" target="_blank">http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-swi<br>
tching-0-7.html</a> . Conceptually it's very similar to how the "st"<br>
parameter is used in the ST monad if you're familiar with that.<br>
<br>
as to scaling, it is possible for a reactive network to scale to fairly<br>
large systems, but not all of them do. I've been meaning to blog about<br>
this soon, maybe over the next week or two.<br>
<br>
John L.<br>
<br>
References<br>
<br>
1. <a href="http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-switching-0-7.html" target="_blank">http://apfelmus.nfshost.com/blog/2012/09/03-frp-dynamic-event-switching-0-7.html</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://www.haskell.org/pipermail/reactive/attachments/20130207/d4748a02/attachment.html" target="_blank">http://www.haskell.org/pipermail/reactive/attachments/20130207/d4748a02/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Reactive mailing list<br>
<a href="mailto:Reactive@haskell.org">Reactive@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/reactive" target="_blank">http://www.haskell.org/mailman/listinfo/reactive</a><br>
<br>
<br>
End of Reactive Digest, Vol 18, Issue 3<br>
***************************************<br>
</blockquote></div><br></div></div></div>