thalerjonathan
commented
6 years ago After thinking about it, I abandon this approach as it can be simulated passing in STM vars as arguments to the agent function, so there is no need to implement the whole Agent API again in STM. Simply too much work which would not pay off and also would require scheduling code to be rewritten completely.
The sequential and parallel update-strategy have pure data-flows between agents: between each step of the simulation the data is routed explicitly. For the concurrent and actor update-strategy we shall utilize STM for data-routing, which requires to rework quite much of the pure interface as the STM monad is then reflected in most of the types (AgentIn/Out/Def). Problem: an agent must then hold a reference to the STM queue of the other agent to be able to send data. The references have to come from somewhere as the AgentIds: which is at the moment from the environment (or hard-coded) - it should work similar.
Note: if one wants pure data-flow between Agents but still have STM functionality, then one should use the pure Agent Interface and put an STM Monad in the transformer stack of the Agent. The STM - related data has then to be passed in as an argument in the initial agent signal-function or through the environment.