It is interesting to note that recent work on AFRP (arrow-based FRP) - namely &quot;Causal Commutative Arrows&quot; -  optimizes a complete circuit of arrows (&quot;interconnected objects&quot; if you prefer to think that way) that all have local state and local feedback loops into one large state and feedback loop,  essentially what optimized imperative simulations also do (e.g. thousands of moving particles that are treated as a single state block of position/velocity pairs). Together with stream fusion the researchers working on this were able to generate optimized code that runs hundreds (!!!) times faster than the best GHC could do. Impressive isn&#39;t it. Unfortunately it will only work on static networks, not those with dynamic switches in it, but I&#39;m pretty sure that within say 5 years, this will all be settled and it will become exiting times for simulation developers, we will finally be pure, lazy *and* fast; it just needs a little push (since it&#39;s now mostly pulling, okay I&#39;ll stop the nonsense, couldn&#39;t resist the nerd talk ;-)<div>
<div><div><div><div><div><br><div class="gmail_quote">On Wed, Aug 19, 2009 at 1:29 AM, Ertugrul Soeylemez <span dir="ltr">&lt;<a href="mailto:es@ertes.de">es@ertes.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Eric Wong &lt;<a href="mailto:wsysdu@gmail.com">wsysdu@gmail.com</a>&gt; wrote:<br>
<br>
</div><div class="im">&gt; I used to think about a physical engine in a similar way, and I think<br>
&gt; it can work. But in some simulations that objects have lots of<br>
&gt; dependencies on others can be tricky. For instance, object o1 depends<br>
&gt; on o2, if we represent them in pure values, when we update o2, then o1<br>
&gt; must be updated with a new o2 value, isn&#39;t it?<br>
<br>
</div>This is something handled best by functional reactive programming.  See<br>
Peter Verswyvelen&#39;s post.  It allows you to encode this purely in an<br>
excitingly elegant way.<br>
<div class="im"><br>
<br>
&gt; Recently I want to implement the digital circuit simulation in SICP<br>
&gt; using Haskell as an exercise. In the Scheme version, each Wire is<br>
&gt; represented as a function with local states. It records the signal on<br>
&gt; the wire and actions it will take when the signal changes to activate<br>
&gt; other wires.  How to represent the Wire in haskell purely?<br>
&gt;<br>
&gt; If I use State Monad (yes, it&#39;s pure :) to repsent a wire with local<br>
&gt; state, the interaction between connected wires is really tricky to<br>
&gt; implement.  any ideas?<br>
<br>
</div>You don&#39;t.  Either you use a state monad to hold _all_ wires (objects)<br>
in, say, a Map, a Set or an Array, or you use a completely different<br>
approach (like FRP).  In other words, your state monad should represent<br>
all wires, not just one, because all wires together make up the state<br>
you want to work with.<br>
<div class="im"><br>
<br>
Greets,<br>
Ertugrul.<br>
<br>
<br>
--<br>
nightmare = unsafePerformIO (getWrongWife &gt;&gt;= sex)<br>
<a href="http://blog.ertes.de/" target="_blank">http://blog.ertes.de/</a><br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">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></div></div></div></div></div></div>