<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<a class="moz-txt-link-abbreviated" href="mailto:apfelmus@quantentunnel.de">apfelmus@quantentunnel.de</a> wrote:
<blockquote cite="midegqb23$csd$1@sea.gmane.org" type="cite">
<pre wrap="">Paul Hudak wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In fact avoiding space leaks was one of the motivations for our moving
to an arrow framework for FRP (now called Yampa). Arrows amount to a
point-free coding style, although with "arrow syntax" the cumbersomeness
of programming in that style is largely alleviated.
</pre>
</blockquote>
<pre wrap="">
I think that's an entirely different thing.
You changed representation of signal transformers from
newtype SF a b = SF ([a] -> [b])
to
data SF a b = SF (a -> (b, SF a b))
</pre>
</blockquote>
I think that you misunderstood what I said. When we went from FRP to
Yampa, we changed from using signals directly, i.e. Signal a, to using
signal
functions, i.e.:<br>
<br>
SF a b = Signal a -> Signal b<br>
<br>
When we did this, we made SF abstract, and we adopted the arrow
framework to allow composing, etc. signal functions. This meant that
you could not get your hands on Signals directly, which helped to
prevent space leaks.<br>
<br>
What you describe above is a change that we made in the <i>implementation</i>
of signal functions (specifically, from streams to continuations),
which indeed is an entirely different thing.<br>
<br>
-Paul<br>
<br>
</body>
</html>