Hi all, 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. Thanks, David ---------- Forwarded message ---------- From: David Sorokin <david.sorokin@gmail.com> Date: Wed, Sep 2, 2015 at 9:39 AM Subject: Re: [Haskell-cafe] How to combine simulations To: martin <martin.drautzburg@web.de> Hi Martin, 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. 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. 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 current discontinuous process waiting for a signal to come. I hope it helps. In case of need, these ideas can be re-implemented. Thanks, David On Mon, Aug 31, 2015 at 7:48 PM, martin <martin.drautzburg@web.de> wrote:

Hello all,

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, that somewhere there must be an operation which takes an Event and maybe emits an Event (and appends to a log and updates some state). Those Events whould come from and go to the "environment" the simulation runs in.

My mental model is two billiard tables, which are connected through a hole in the cushion and which each have a player. 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 send events to its player ("all balls at rest") and to the other table.

If I add the other table and the two players then the combined simulation would not emit any events at all and it would not respond to any events except maybe as START event. It would only depend on its initial state.

But if I add only the player, but not the other table, it would still send events to the other table and respond to events from that other table.

My problem is the type of Events. I could create a type which encompasses all possible events, but that violates the idea of composablitly. Somehow I would need to be able to take a system which accepts "player events" and "other table events", compose it with an other table and end up with a system which only accepts "player events" but no more "other table events" and similarly for the emitted events. And I don't quite know how to do this.

Hope this makes some sense.

Any pointers (which go beyond "aivika has a simulation component") would also be much appreciated. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe