[Haskell-cafe] IO and State

[Ben Rudiak-Gould]

Iavor S. Diatchki wrote:

> Ben Rudiak-Gould wrote:
>
>> I would say that the law holds in one direction and not the other. [...]
>
> How can things be equal the one way and not the other?

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. :-)

>> The semantics for concurrency don't guarantee that a task switch will 
>> /never/ happen between two calls of readIORef, but they don't 
>> guarantee that a task switch will /ever/ happen, either, so relying 
>> on your sample application terminating is non-portable. Therefore 
>> optimizing it in such a way that it never terminates is safe.
>
> My example had nothing to do with non-termination.

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

> It illustrated that with the one piece of code, a boolean value in the 
> program will be always True,
> while with the other it could become False [...]

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

-- Ben