hi,<br><br><div class="gmail_quote">On Wed, Jun 25, 2008 at 2:36 PM, Sven-Olof Nystr|m <<a href="mailto:svenolof@it.uu.se">svenolof@it.uu.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Vlad Dumitrescu writes:<br></div><div class="Ih2E3d"> > Regarding channels, there are several other paradigms that might be<br>
 > interesting to explore. One is the "process as stream processor" one, where<br>
 > processes work just like the UNIX toolkit programs by processing input<br>
 > messages and sending them forward. This allows piping of processes to<br>
 > compose functionality. With an appropriate syntax and machinery, the<br>
 > programmer need only specify the relevant functionality desired.<br>
<br>
</div>I was going to explain how this could be easily implemented in Erlang<br>
but now I see that you have already done that :-) These are of course<br>
ancient ideas; the data flow languages are very similar. You might<br>
find the paper by Jack Dennis (referred to in my paper) worth reading.<br></blockquote></div><br>Of course it's not a new idea. It's just that I didn't see before that the data flow paradigm is so easily mappable onto Erlang.<br>
<br>I think that a simple framework like I described before is relatively easy to implement. Probably the most difficult part would be the to decide a good syntax :-) The really useful stuff is more complicated: flow control, fault tolerance. Also, I suppose linear pipes are nice enough, but Hartmann pipelines (<a href="http://en.wikipedia.org/wiki/Hartmann_pipeline">http://en.wikipedia.org/wiki/Hartmann_pipeline</a>) are even cooler!<br>
<br>So many ideas, so little time... :-)<br><br>best regards,<br>Vlad<br><br>