<div dir="ltr">Which FRP frameworks have you been looking at?<div style><br>In my experience, the most publicized leaks have been time leaks, which are a particular type of memory leak related to switching. However, the presence of time leaks mostly arises in terms of the FRP implementation. Arrowized FRP (e.g. Yampa, netwire) do not typically suffer from this for example. Some libraries that implement the semantics of Conal Elliott's "Push-pull functional reactive programming" (or similar semantics) have been susceptible to this, however recent implementations are not. Sodium, elerea, and reactive-banana for example have generally overcome the worst issues present in earlier systems. Leaks can still be present in current systems of course, but now they're generally due to the programmer unintentionally retaining data in a case that's much simpler to reason about. That is, the situation today is more similar to forgetting to use deepseq or similar, rather than the prior leaks that were very difficult to reason about.</div>
<div style><br></div><div style>I think the most common current issue is that a very natural way of accumulating reactive events across time can leak. Suppose you have a library of reactive widgets, where each widget has an associated stream of IO actions that you want to run. E.g. clicking a button prints it, sliding a scale prints the value, etc.</div>
<div style><br></div><div style>> class Actionable a where</div><div style>> actions :: a -> Event (IO ())</div><div style><br></div><div style>suppose you have a collection that allows you to add/remove Actionable things to it (e.g. a button panel). This panel has an action stream that's simply the concatenation of those of its components. One possible implementation looks like this:</div>
<div style><br></div><div style>> data ButtonPanel = ButtonPanel (Event (IO ())</div><div style><br></div><div style>> emptyPanel = ButtonPanel mempty</div><div style><br></div><div style>> addActionable :: Actionable a => ButtonPanel -> a -> ButtonPanel</div>
<div style>> addActionable (ButtonPanel e) a = ButtonPanel (e <> actions a)</div><div style><br></div><div style>I've omitted all the parts for wiring up the gui, but suppose they're handled also, and removing a button from the panel just removes it from the gui and destroys the widget. After that, the button's event stream is empty, so you can just leave the ButtonPanel's event stream unchanged, because the destroyed button will never fire.</div>
<div style><br></div><div style>This is a memory leak. The destroyed Button's event stream is still referenced in the ButtonPanel event stream, so data related to it never gets freed. Over time your FRP network will grow, and eventually you'll hit scaling problems.</div>
<div style><br></div><div style>The proper solution in this instance is to keep a list of each button's event stream within the button panel. It's ok to keep a cached aggregate stream, but that cache needs to be re-built when a button is removed. This is usually fairly natural to do with FRP, but your ButtonPanel may look like this instead:</div>
<div style><br></div><div style>> data ButtonPanel = ButtonPanel (Map Key (Event (IO ()))</div><div style><br></div><div style>> addActionable :: Actionable a => ButtonPanel-> Key -> a -> ButtonPanel</div>
<div style>> removeActionable :: ButtonPanel -> Key -> ButtonPanel</div><div style><br></div><div style>and now you need to manage some sort of Key for collection elements.</div><div style><br></div><div style>This style isn't entirely idiomatic FRP. Instead of these functions, you could have all your modifications handled via the FRP framework. For example,</div>
<div style><br></div><div style>> data ButtonPanel = ButtonPanel (Behavior (Map Key (Event (IO ()))))</div><div style>> buttonPanel :: Actionable a => Event (Key,a) -> Event Key -> ButtonPanel<br></div><div style>
<br></div><div style>but you still need to be aware that objects can reference older objects. Behaviors are frequently created via accumulators over events (e.g. accumB), and if the accumulation is doing something like 'mappend', a memory leak is likely.</div>
<div style><br></div><div style>Basically, the issue is that when you're accumulating reactive stuff over time, you need to be sure that your accumulator doesn't reference data that is otherwise expired. This example uses a push-pull style pseudocode because that's what I'm most familiar with. I'm not entirely show how (or if) this translates to arrowized FRP, although it wouldn't surprise me if there's a similar pattern.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 2:50 AM, Łukasz Dąbek <span dir="ltr"><<a href="mailto:sznurek@gmail.com" target="_blank">sznurek@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello, Cafe!<br><br></div>I've heard that one of the problems of FRP (Functional Reactive Programming) is that it's easy to create memory leaks. However I cannot find any natural examples of such leaks. Could anybody post some (pseudo)code demonstrating this phenomenon? Preferably something that arises when one is writing bigger applications in FRP style.<br>
<br></div>Thanks in advance!<br><br>--<br></div>Łukasz Dąbek<br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>