"Patai Gergely"
I don't agree. A concurrent change is the effect of an IO action, not of the thread. For example if a concurrent thread writes to an MVar, then that change becomes the effect of the next takeMVar, which gets executed. If a concurrent thread changes a file on disk, then that changing becomes the effect of the next readFile, which reads the changed file.
But that's exactly what the model cannot handle. Look at the following snippet again:
let (x, world1) = getLine world0 world2 = print (x+1) world1
This clearly says that the world returned by getLine and the world consumed by print is the same one, since the state monad model is pure, therefore world1 is immutable. However, this is not true, since someone else could have modified it in the meantime. The state monad can only describe a single thread, but that's a non-existent situation in the case of I/O, since the world keeps changing outside the program even if the program itself is single-threaded.
No. As you say the world1 value is immutable, but that's not contradictory. If between 'getLine' and 'print' something was done by a concurrent thread, then that change to the world is captured by 'print'. See for example the following code: var <- newEmptyMVar forkIO $ threadDelay 1000000 >> putMVar var 15 takeMVar var >>= print Let's translate it: \world0 -> let (var, world1) = newEmptyMVar world0 world2 = (forkIO $ threadDelay 1000000 >> putMVar var 15) world1 (result, world3) = takeMVar var world2 in print result world3 The subthread has the following code: \world0 -> let world1 = threadDelay 1000000 world0 in putMVar var 15 world1 In the main thread the delay of one second and the change to the MVar is /not/ an effect of another thread. There is no notion of threads at all. It's a side effect of takeMVar. The thread launched by forkIO becomes part of the opaque world variable, which captures everything. Otherwise we would have to say that the state monad model doesn't capture user input either, because conceptually there is no difference between a user typing something and a concurrent thread writing to stdin. IO has no specific notion for threads. Threads are just side effects. Things caused by threads is captured by normal IO actions like getLine and takeMVar. That's not a flaw of the interpretation as a state monad. That's a flaw of the IO monad itself. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/