<br><div class="gmail_quote">On Fri, Oct 14, 2011 at 1:31 AM, Ertugrul Soeylemez <span dir="ltr">&lt;<a href="mailto:es@ertes.de">es@ertes.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">David Barbour &lt;<a href="mailto:dmbarbour@gmail.com">dmbarbour@gmail.com</a>&gt; wrote:<br>
<br>
&gt; If you want first-class behaviors or behavior transformers, those will<br>
&gt; need a different abstraction than &#39;nested&#39; behaviors. Nested != First<br>
&gt; Class.  You&#39;d have special functions to lift a first-class behavior as<br>
&gt; an argument (e.g. add a phantom type to prohibit non-causal<br>
&gt; observation), and to lower it into the main system for sampling<br>
&gt; (e.g. ArrowApply).<br>
<br>
</div>The usual model for arrowized FRP is based on this type:<br>
<br>
    newtype Auto a b = Auto (a -&gt; (b, Auto a b))<br>
<br>
I would be very interested in how you would write an ArrowApply instance<br>
for such a type.  So far my conclusion is:  It&#39;s impossible.<br></blockquote><div><br></div><div>Interesting claim. The implementation is obvious enough:</div><div>  runAuto (Auto f) = f</div><div>  app = Auto $ \ (f,x) -&gt; let (x&#39;,f&#39;) = runAuto f x in (x&#39;,app)</div>
<div><br></div><div>Which arrow laws does this violate? Or is your concern that a fresh arrow supplied to `app` at each instant obviously cannot accumulate state?</div><div><br></div><div>Yampa AFRP model chooses to model products using the `Either` type - i.e. indicating that either element can be updated independently.  Using this, one could accumulate state in the captured arrow, though there&#39;d be a funky reset whenever the arrow is updated. </div>
<div><br></div><div>Getting back on topic, protecting causality requires that we prevent sampling of a first-class Auto element. One way to do this is to use a Rank2Type similar to the ST monad:</div><div><br></div><div>  newtype Auto era a b = Auto { unAuto :: a -&gt; (b, Auto era a b) }</div>
<div>  runAuto :: (forall era . Auto era a b) -&gt; [a] -&gt; [b]</div><div><br></div><div>This would prevent developers from `running` an Auto of a known era, except by protected mechanisms such as ArrowApply.  Simulations would need to be era-independent.</div>
<div><br></div><div>The reactive model I&#39;m developing, Reactive Demand Programming, is actually anti-causal: behavior at any given instant may depend only upon its present and future inputs (anticipation), but never the past. State is treated as an external service, part of an abstract machine, orchestration of registers or a database. I think this setup works better than FRP, e.g. for controlling space-leaks, supporting smooth transitions and upgrades of dynamic behavior, modeling the app as a whole as dynamic, and orthogonal persistence.</div>
<div><br></div></div>