Re: [reactive] switching events = space leak?
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
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....
On Feb 8, 2013, at 1:13 AM, John Lato wrote:
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.
one sentence in the package documentation is holding me back from using event switching: "There is currently no garbage collection for dynamically created events." any ideas how much work it would be to to fix this? how does sodium compare in this regard? (cc'ing reactive-banana's author in case he's interested in joining the discussion here ...) sk
From: Don Vincenze
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....
sodium and elerea both have garbage collection for dynamically created
events. However, in practice I find we often need to call performGC to
make it happen, because ghc's runtime doesn't seem to schedule major gc's
often enough. But that may only be because we run our reactive app at full
tilt, so there are very few unused cycles already.
I don't think it would be all that difficult to add support for this to
reactive-banana, but Apfelmus indicated there are a few design issues that
need to be resolved when I last discussed this with him. That was a few
months ago though, so maybe he's made some progress.
John
On Fri, Feb 8, 2013 at 5:59 PM, Stefan Kersten
On Feb 8, 2013, at 1:13 AM, John Lato wrote:
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.
one sentence in the package documentation is holding me back from using event switching:
"There is currently no garbage collection for dynamically created events."
any ideas how much work it would be to to fix this? how does sodium compare in this regard?
(cc'ing reactive-banana's author in case he's interested in joining the discussion here ...)
sk
From: Don Vincenze
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....
participants (2)
-
John Lato -
Stefan Kersten