> 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. Gergely -- http://www.fastmail.fm - IMAP accessible web-mail _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
