[Haskell-cafe] Replacing the world in a State Machine with IO

martin martin.drautzburg at web.de
Sun Nov 23 17:04:37 UTC 2014


Hello all,

at my shop some folks are implementing things using a java tool called "activiti". AFAIK, they create a bunch of
processes and a "process engine" takes care of activating or deactivating processes. Among the things which can cause a
state transition are external events. I wonder how one could do this in haskell.


(1) Async IO

I thought the collection of all process states can be seen as the system state of a state machine. Some state
transitions can be done without doing IO, e.g. in situations where the termination of one processes immediatlely
activates another process. However other transitions block and occur as soon as an external event is received. Yet other
transitions occur WHENEVER an external event gets received.

I suppose I could handle this using threads, but I don't trust threads. They look simple first, but then the trouble
they cause typically exceeds my worst expectations.

My primary problem is that I haven't yet found a proper way to fully capture the problem. It appears to me that a state
machine without IO is essentially a discrete event simulation. A state machine where ALL state transitions are triggered
by IO also seems easy, everything would be blocking and I just dispatch external events. But I cannot picture a state
machine where some (but not all) transitions are triggered by IO.


(2) Replacing the real world

In the long run, I'd like to replace the "world" from which these events originate by a simulated world. This should
allow the process engine to proceeed in fast motion. I suppose I will then also make the clock part of the simulated world.

This raises the question: how does one replace IO? The simulated world will not do any real IO (but still communicate to
the process engine). Considering that "IO a" basically means "World -> (World, a)" this should be easy, but I cannot see
how to get a hold on "World".


If someone could give my thoughts a push in the right direction, I'd much appreciate it.


More information about the Haskell-Cafe mailing list