[Haskell-cafe] IO and State

[Iavor S. Diatchki]

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".