<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. Signal transformers model interactive behaviors, where the behaviors/signals of classic FRP model non-interactive behaviors. (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> .) I also like currying.<br>
<br>As long as we use not just the arrow abstraction but also <i>arrow notation</i>, I don't know how we'll ever be able to get an efficient implementation, in which portions of computed signals get recomputed only when necessary. And probably the Arrow abstraction itself is a bit too restrictive, given that it disallows any conditions on its type arguments. So I've been noodling some about formulations of signal functions that don't fit into the standard arrow discipline.<br>
<br>Regards, - Conal<br><br><div class="gmail_quote">On Fri, Dec 19, 2008 at 6:31 AM, Paul L <span dir="ltr"><<a href="mailto:ninegua@gmail.com">ninegua@gmail.com</a>></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>
z <- sf2 <<< sf1 -< 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>
f <*> x <*> y<br>
<br>
where f can have the type Behavior a -> Behavior b -> Behavior c. I<br>
don'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>
z <- sf -< (x, y)<br>
<br>
The tupling may seem an extra burden, but it's an inherent design<br>
choice of arrows, which builds data structure on top of products, and<br>
people can'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>