Patai, I read your paper on Elerea. It wasn&#39;t easy :), but I think I got the picture.<br>So I would have 2 questions :<br><br>I made a simple function which turns an infinite list into a signal :<br><br><span style="font-family: courier new,monospace;">fromList :: [a] -&gt; SignalGen (Signal a)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">fromList xs =</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">  stateful xs tail &gt;&gt;= memo . fmap head</span><br>
<br>1) It does what I want, but is it the good way to do it?<br>2) Since the returned signal may be used in several places and since I obtain it through the generic fmap (and not through an Elerea primitive), I guessed I had to &quot;memo&quot; it instead of simply using &quot;return&quot;. Did I guess right?<br>
<br>3) Concerning the functionnality added by the Param implementation, I have the impression that the same can be achieved through the use of an external signal in Simple (*). Am I right? If so, why did you make the Param alternative?<br>
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">(*) (ext, sink) &lt;- external &#39;a&#39;<br>    driver &lt;- start $ someSigGen ext<br>    sink &#39;b&#39;<br>    driver<br>
    sink &#39;c&#39;<br>    driver<br>    sink &#39;d&#39;<br>    driver<br>etc...<br></span><div class="gmail_quote"><br><br>2010/12/16 Patai Gergely <span dir="ltr">&lt;<a href="mailto:patai_gergely@fastmail.fm">patai_gergely@fastmail.fm</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">&gt; So in the result of (a &gt;&gt;= f), the first element is taken from the<br>

&gt; first element of applying f to the first element of a; the second<br>
&gt; element is the second element in the result of applying f to the second<br>
&gt; element of a; and so on.  Off the top of my head I am not sure what<br>
&gt; this corresponds to in terms of agents or where it would be useful,<br>
&gt; but I&#39;m sure it must correspond to something interesting.<br>
</div>In short, join corresponds to continuously sampling a stream of streams.<br>
In other words, it turns a higher-order stream into a dynamic data-flow<br>
network. That&#39;s exactly what the Elerea library [1] is good for: it<br>
allows you to do this in constant time instead of the quadratic cost of<br>
the pure implementation, but it forces you to traverse streams<br>
sequentially -- fortunately, that&#39;s exactly what you want to do most of<br>
the time. There is also a paper behind the library, which might help a<br>
bit in getting a clearer picture [2] (the paper also has an updated<br>
version in the process of being published).<br>
<br>
Gergely<br>
<br>
[1] <a href="http://hackage.haskell.org/package/elerea" target="_blank">http://hackage.haskell.org/package/elerea</a><br>
[2]<br>
<a href="http://sgate.emt.bme.hu/documents/patai/publications/PataiWFLP2010.pdf" target="_blank">http://sgate.emt.bme.hu/documents/patai/publications/PataiWFLP2010.pdf</a><br>
<font color="#888888"><br>
--<br>
<a href="http://www.fastmail.fm" target="_blank">http://www.fastmail.fm</a> - One of many happy users:<br>
  <a href="http://www.fastmail.fm/docs/quotes.html" target="_blank">http://www.fastmail.fm/docs/quotes.html</a><br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<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>