<div dir="ltr">It might be worth your while to look at netwire or auto, which both use arrows to model networks.<br><br>Ben</div><br><div class="gmail_quote">On Tue, 31 Mar 2015 at 06:35 martin <<a href="mailto:martin.drautzburg@web.de">martin.drautzburg@web.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
little do I know about arrows, but the "stream processor" metaphor suggests, that they can be used to simulate a network<br>
of things, services or data. Is this correct?<br>
<br>
I came across the following thought: When I simulate a billard game with a DES, I would compute collisions of balls with<br>
each other and with the banks, creatign a set of events, of which only the earliest will be considered to compute the<br>
next state. This is pure DES and does not seem to be a good candidate for arrows. In this case I'd be more interested in<br>
composing collision detectors than in stream processing.<br>
<br>
OTOH, when I move parcels around and process then in various stages, then a "stream processor" would make perfect sense<br>
to me. In that case, would I abandon the DES paradigm entirely (including the notion of an event queue) and just model<br>
the network and let it run?<br>
<br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
</blockquote></div>