[Haskell-cafe] IO and State
Benjamin.Rudiak-Gould at cl.cam.ac.uk
Fri Nov 12 18:54:46 EST 2004
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".
More information about the Haskell-Cafe