<div dir="ltr"><div><div><div>Hi all,<br><br></div>I forgot to click on ReplyAll. I thought that my answer could be interested to others as well. Therefore, I resend the letter to Haskell Cafe.<br><br></div>Thanks,<br></div>David<br><div><div><div><div><div><div><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">David Sorokin</b> <span dir="ltr"><<a href="mailto:david.sorokin@gmail.com">david.sorokin@gmail.com</a>></span><br>Date: Wed, Sep 2, 2015 at 9:39 AM<br>Subject: Re: [Haskell-cafe] How to combine simulations<br>To: martin <<a href="mailto:martin.drautzburg@web.de">martin.drautzburg@web.de</a>><br><br><br><div dir="ltr">Hi Martin,<br><br>Nevertheless, regarding Aivika, did you look at the Signal type (inspired by the IObservable interface of .NET)? This type is quite composable. If I understood you correctly, the Signal is what you call Event.<br><br>Moreover, if you need a mutable state, then you could use the Ref reference and its signal refChanged. For example, the reference could be used to decide whether to emit a signal based on the intermediate state.<br><br>Furthermore, if you want to build a computation with linear-looking signal processing then you could use the Process monad (inspired by the Async workflow of F#) and the processAwait function that suspends the <br>current discontinuous process waiting for a signal to come.<br><br>I hope it helps. In case of need, these ideas can be re-implemented.<br><br>Thanks,<br>David<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 7:48 PM, martin <span dir="ltr"><<a href="mailto:martin.drautzburg@web.de" target="_blank">martin.drautzburg@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
I've been trying hard to come up with an idea how to build a DES from smaller parts. So far, I came to the conclusion,<br>
that somewhere there must be an operation which takes an Event and maybe emits an Event (and appends to a log and<br>
updates some state). Those Events whould come from and go to the "environment" the simulation runs in.<br>
<br>
My mental model is two billiard tables, which are connected through a hole in the cushion and which each have a player.<br>
When I look at one such table, it would have to respond to Events from its player and from the other table and it would<br>
send events to its player ("all balls at rest") and to the other table.<br>
<br>
If I add the other table and the two players then the combined simulation would not emit any events at all and it would<br>
not respond to any events except maybe as START event. It would only depend on its initial state.<br>
<br>
But if I add only the player, but not the other table, it would still send events to the other table and respond to<br>
events from that other table.<br>
<br>
My problem is the type of Events. I could create a type which encompasses all possible events, but that violates the<br>
idea of composablitly. Somehow I would need to be able to take a system which accepts "player events" and "other table<br>
events", compose it with an other table and end up with a system which only accepts "player events" but no more "other<br>
table events" and similarly for the emitted events. And I don't quite know how to do this.<br>
<br>
Hope this makes some sense.<br>
<br>
Any pointers (which go beyond "aivika has a simulation component") would also be much appreciated.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>
</div></div></div><br></div></div></div></div></div></div></div>