On Sunday, August 15, 2010, Tillmann Rendel
Bulat Ziganshin wrote:
But in a world passing interpretation of IO, print is supposed to be a pure Haskell function. So the value world2 can only depend on the values of print and world1, but not on the actions of some concurrent thread.
the whole World includes any concurrent thread though ;)
Oh I see. So given world1, print can simulate the behavior of the concurrent thread to take it into account when constructing world2. Since that simulation depends only on world1, print is still pure.
Does that mean that world passing *does* account for concurrency after all?
Tillmann _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I guess I don't see how forkIO, MVar's etc are more problematic than any other kind of I/O. Consider: line <- hGetLine myHandle putStrLn line The "world" could very easily change between these two statements - someone could delete the file we're reading from or change its contents or truncate it. In fact, the "RealWorld" will always be in flux and will never, ever be the same from one call to the next (even consider things like the wall clock, which will tick in between the time you generated world0 and the time you pass world0 to a new IO action). I don't think threads are the only problem with the "State RealWorld a" interpretation.