<div class="gmail_quote">On Fri, Oct 7, 2011 at 3:17 AM, Heinrich Apfelmus <span dir="ltr">&lt;<a href="mailto:apfelmus@quantentunnel.de">apfelmus@quantentunnel.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
FRP is somewhat orthogonal to incremental computation because FRP is focusing on expressiveness while incremental computation focuses on performance. You can formulate some incremental algorithms in terms of FRP, but you need special support from the implementation to make it efficient. </blockquote>
<div><br></div><div>Granted. The &#39;Reactive&#39; library provides some special support for composing constant behavior values, but I share your doubts about its suitability for high-performance incremental computation. By my understanding from Push-Pull FRP, it should scale poorly in terms of linear &#39;checks&#39; of promises when trying to find which variables have changed. If you have 1000 variables you still might need to probe up to 1000 promises (or more, if you use vars more than once) to see their next time-of-change.</div>
<div><br></div><div>My asynchronous arrows and reactive demand programming model is well suited for incremental computation, having been designed for scalability and distributed computation (breaking it into multiple pipelines with minimal synchronization interactions at zip and merge). But it currently lacks a complete implementation.</div>
<div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Even then, events and behaviors are &quot;one abstraction level too low&quot;. In my opinion, you are better off with a library/approach geared directly towards incremental computations.<br>
</blockquote><div><br></div><div>I believe behaviors are precisely the &#39;right&#39; abstraction if the goal is to model variables in a computation changing over time. But I agree that, if the libraries aren&#39;t taking advantage of the implicit optimization opportunities, you are better off finding libraries that do.</div>
<div><br></div><div>Regards,</div><div><br></div><div>Dave</div></div>