Preventing space leaks

[josh]

Does sodium yet have any mechanism to avoid the space leaks associated with frp?

E.g. Frpnow paper

[clinuxrulz]

Short answer minimize/be careful with switchC / switchS. They are the only two functions that can be introduce a space leak. Older monadic frp implements had bind as a primitive so leaks used to be more common.

[clinuxrulz]

I'll expand the answer a little.

Space leak occur when we are continuous creating more frp nodes in a way they retain a strong reference even though they may never be used again. And the graph just keeps growing while its evaluated.

Sodium uses Weak References pointing forwards to frp nodes that are effected by a change in a frp node. And if you stick to the applicative functor interface provided your safe. switchC / switchS is pretty safe too as long as it is not miss used.

Older monadic frp implementations provided bind which made it too easy to keep recreating frp nodes which only needed to be created once (evaluation of bind continuation repetitively), and also if you accidentally created a monadic loop you get in that situation where you keep creating more strongly referenced frp nodes continuously that never get released even through they may never be used again (strong reference capture by lambda in bind's continuation). This is still possible, but harder to do in sodium. switchC is like join, and a map with a join used together is the same as bind.

[the-real-blackh]

The old FRP space leaks that people had trouble with were related to the way that Conal had implemented his library, which is very different to Sodium and the other FRP systems that are like it. The same problem doesn't exist in these implementations.

However, as @clinuxrulz pointed out, space leaks are still possible in Sodium. But it's pretty unlikely you will write them by accident.

[dakom]

Sounds like a good candidate for a Wiki article... is there some simple sample code you'd suggest for demonstrating how it can accidentally happen?

[dakom]

I'm curious to hear more thoughts about the comparison to that paper linked above... seems like there's a Typescript implementation underway too at https://github.com/funkia/hareactive

Not asking anything specific, from my perspective feel free to think out loud in comparing this to Sodium

[huanhulan]

Maybe my zombiecus demo can demonstate this issue https://huanhulan.github.io/zombicus/

[cubuspl42]

I believe that you can very easily have a Sodium space leak if you're recursively using Conal's switcher (in Sodium expressed as switchC . hold) with a Stream that is known to fire only once, typically received from Stream.once(). Such stream is equivalent to Event (following the 1997 "Functional Reactive Animation" paper nomenclature) or Future ("Push-Pull Functional Reactive Programming" paper nomenclature; although it wasn't really a semantic element there). I believe that conceptually, such construction can be optimized similarly to tail-call optimization in FP implementations. The construction I'm talking about isn't exotic at all, in my opinion for some every-day problems it's the only conceptually correct one.