February 2013 - Reactive

Re: [reactive] switching events = space leak?
by John Lato 11 Feb '13

11 Feb '13

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(a)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… >

2 2

Re: [reactive] switching events = space leak?
by John Lato 06 Feb '13

06 Feb '13

Hello, > From: Don Vincenze <don(a)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…. 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.

2 1

switching events = space leak?
by Don Vincenze 05 Feb '13

05 Feb '13

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 is made a bit clearer in the book "The Haskell School of Expression", chapter 15, which as I understand describes the implementation of Yampa, not "reactive". However there isn't a difference between the two in that respect as far as I can read the code, or is there? Such as space leak would not just be a bug but would need some design rework. Don

2 2