<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">The example Henrik gave [...] models a composition, and is in general the strength of a<br>
combinator approach. But the strength of Applicative, in my opinion,<br>
is not composition but currying [...]<br></blockquote>

<br>Well put, Paul.<br><br>I really do like the semantic model of Yampa.&nbsp; Signal transformers model interactive behaviors, where the behaviors/signals of classic FRP model non-interactive behaviors.&nbsp; (See <a href="http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-behavior/">http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-behavior/</a> .)&nbsp; I also like currying.<br>
<br>As long as we use not just the arrow abstraction but also <i>arrow notation</i>, I don&#39;t know how we&#39;ll ever be able to get an efficient implementation, in which portions of computed signals get recomputed only when necessary.&nbsp; And probably the Arrow abstraction itself is a bit too restrictive, given that it disallows any conditions on its type arguments.&nbsp; So I&#39;ve been noodling some about formulations of signal functions that don&#39;t fit into the standard arrow discipline.<br>
<br>Regards,&nbsp; - Conal<br><br><div class="gmail_quote">On Fri, Dec 19, 2008 at 6:31 AM, Paul L <span dir="ltr">&lt;<a href="mailto:ninegua@gmail.com">ninegua@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Nice to see this discussion, and I just want to comment on the<br>
applicative v.s. arrow style. The example Henrik gave is<br>
<br>
 &nbsp;z &lt;- sf2 &lt;&lt;&lt; sf1 -&lt; x<br>
<br>
which models a composition, and is in general the strength of a<br>
combinator approach. But the strength of Applicative, in my opinion,<br>
is not composition but currying:<br>
<br>
 &nbsp;f &lt;*&gt; x &lt;*&gt; y<br>
<br>
where f can have the type Behavior a -&gt; Behavior b -&gt; Behavior c. I<br>
don&#39;t think there is an exact match in arrows. One could, however,<br>
require sf to be of type SF (a, b) c, and write<br>
<br>
 &nbsp;z &lt;- sf -&lt; (x, y)<br>
<br>
The tupling may seem an extra burden, but it&#39;s an inherent design<br>
choice of arrows, which builds data structure on top of products, and<br>
people can&#39;t run away from it when writing arrow programs.<br>
<font color="#888888"><br>
--<br>
Regards,<br>
Paul Liu<br>
<br>
Yale Haskell Group<br>
<a href="http://www.haskell.org/yale" target="_blank">http://www.haskell.org/yale</a><br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<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>
</div></div></blockquote></div><br>