In a post in the <b>Elerea, another FRP library </b>thread<b>,</b> Peter Verswyvelen wrote:<br>
<br>
<i>&gt;I think it would be nice if we could make a &quot;reactive benchmark&quot; or
something: some tiny examples that capture the essence of reactive
systems, and a way to compare each solution&#39;s &gt;pros and cons.</i>
<div><i><br></i></div>

<div><i>&gt;For example the &quot;plugging a space leak with an arrow&quot; papers reduces the recursive signal problem to<br></i></div>
<div><i><br></i></div>
<div><i>&gt;e = integral 1 e</i></div>
<div><i><br></i></div>
<div>
<i>&gt;Maybe the Nlift problem is a good example for dynamic collections, but I guess we&#39;ll need more examples.</i></div>


<div><i><br></i></div>
<i>&gt;The reason why I&#39;m talking about
examples and not semantics is because the latter seems to be pretty
hard to get right for FRP?</i><br>
<br>
I would like to come back to this
exemple. I am trying to write a small FRP in F# (which is a strict
language, a clone of Ocaml) and I also came across space and/or time
leak. But maybe not for the same reasons...<br>


<br>
Thinking about these problems and after some trials and errors, I came to the following conclusions:<br>
<br>
I believe that writing the expression <br>
<br>
      e = integral 1 <i>something</i><br>
<br>
      where e is a Behavior (thus depends on a continuous time). <br>

<br>
has really two different meanings.<br>

<br>
1. if <i>something </i>is independent of e, what the above expression
means is the classical integration of a time dependent function
between t0 and t1. Several numerical methods are available to compute
this integral and, as far as I know, they need to compute <i>something </i>at t0, t1 and, possibly, at intermediate times. In this case, <i>something </i>can be a Behavior.<br>


<br>
2. If <i>something </i>depends directly or indirectly of e then we are faced with a first order differential equation of the form:<br>
   <br>
       de/dt = <i>something</i>(e,t)<br>
<br>
    where de/dt is the time derivative of e and  <i>something</i>(e,t) indicates that <i>something</i> depends, without loss of generality, on both e and t.<br>


<br>
There exist specific methods to numerically solve differential
equations between t0 and t1. Some of them only require the knowledge of
e at t0 (the Euler method), some others needs  to compute <i>something </i>from intermediate times (in [t0, t1[ ) <b>and </b>estimates of e at those intermediary times.<br>


<br>
3. <i>something </i>depends (only) on one or more events that, in
turns, are computed from e. This case seems to be the same as the first
one where the integrand can be decomposed into a before-event
integrand and an after-event integrand (if any event has been
triggered). Both integrands being independent from e. But I have not
completely investigated this case  yet...<br>

<br>
Coming back to my FRP, which is based on residual behaviors, I use a specific solution for each case.<br>
<br>
Solution
to case 1 causes no problem and is similar to what is done in classical
FRP (Euler method, without recursively defined behaviors). Once again
as far as I know...<br>

<br>
The second case has two solutions:<br>

1. the &#39;integrate&#39; function is replaced by a function &#39;solve&#39; which has the following signature <br>
     <br>
       solve :: a -&gt; (Behavior a -&gt; Behavior a) -&gt; Behavior a<br>
      <br>
      In fact,  <i>something</i>(e,t)
is represented by an integrand function from behavior to behavior, this
function is called by the integration           method. The integration
method is then free to pass estimates of e, as constant behaviors, to
the integrand function.<br>

<br>

      The drawbacks of this solution are:<br>
      - To avoid
space/time leaks, it cannot be done without side effects (to be honest,
I have not been able to  find a solution without assignement). However
these side effects are not visible from outside of the solve function. ..<br>


      - If behaviors are defined within the integrand function, they are not accessible from outside of this integrand function.<br>
<br>
2. Introduce constructions that looks like to signal functions.<br>
<br>
      solve :: a -&gt; SF a a -&gt; Behavior a<br>


<br>
   where a SF is able to react to events and may manage an internal state.<br>
   This solution solves the two above problems but make the FRP a bit more complex. <br>
<br>
<br>
Today, I tend to prefer the first solution, but what is important, in my opinion, is to recognize the fact that <br>


<br>
     e = integral 1 <i>something</i><br>
<br>
really addresses two
different problems (integration and solving of differential equations)
and each problem should have their own solution. <br>
<br>
The consequences are :<br>

<ol><li>There is no longer any need for my FRP to be able to define a
Behavior recursively. That is a good news for this is quite tricky in
F#. Consequently, there is no need to introduce delays.</li><li>Higher
order methods for solving of diff. equations can be used (i.e.
Runge-Kutta). That is also good news for this was one of my main goal
in doing the exercice of writing a FRP.</li></ol>
Regards,<br>
<br>
J-C