Hello, I see now what you meant, thanks for the explanation. I find the argument a bit disturbing, as it seems to imply that it is OK for the compiler to produce code without any context switches at all (after all none of the context swicthes are guaranteed to happen :-). I guess this is not true when MVar's and other syncronization primitives are taken into account, e.g. the semantics could say that a context switch will definately occur when a thread blocks on an empty MVar. In any case, the above comments further emphasizes the original point of my post, namely that the IO monad is not a state monad as we know it: in a state monad there is a close relationship between reads and writes to the state, as only the program modifies the state. In the IO monad, the two are much more unrealted, as the real world can change on its own, and thus there are no guarantees that there is any realtionship between reads and writes. A simplistic example to illustrate my point might be that reading a file twice does not guarantee that we get the same contents, or writing to a file, and then reading it, does not guarantee that we get what we wrote. -Iavor Ben Rudiak-Gould wrote:
... Saying that two things are equal means (in this context) that either can be replaced by the other without changing the semantics. In other words, the first can be replaced by the second without changing the semantics, and the second can be replaced by the first without changing the semantics. One of those replacements is valid and the other invalid (I argue). Of course it follows that the two things are not equal -- i.e. I agree with you. :-) ... Nor did my response. I could change the ending to: "[...] so relying on (x == y) ever being False is non-portable. Therefore optimizing it in such a way that it is never False is safe." ... Right, in the first piece of code the expression is guaranteed to be True, while in the second there are no guarantees -- the value could be True or False each time. Therefore it's safe to transform the second expression into the first during optimization, because "always True" is a special case of "anything at all".