Hello,
Ben Rudiak-Gould wrote:
> ...
> I would say that the law holds in one direction and not the other.
> It's safe to replace
>> do x <- readSTRef r
> y <- readSTRef r
>> with
>> do x <- readSTRef r
> let y = x
>> but not the other way around.
How can things be equal the one way and not the other?
I must be misunderstanding what you are saying...
As my little program showed these two pieces of code are not the same,
so they cannot be arbitrarily replaced anywhere in the program.
In the previous email I was trying to exaplin that I think they are the same
as long as they occur in the context of runST. Of course there are many
other
contexts where the two are equivalent... The important thing is that
there is a context
that can tell them apart, and so they are not the same.
> 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.
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 (this is when the program
stopped, but you cold of course
do other things too). Thus, depending on which piece of code you use
your program could have a
completely different behaviour, and so the law I was talking about does
not hold.
What concurrency semantics are you reffering to? GHC provides preemtive
concurrency, Hugs provides
non-preemptive concurrency. The two are quite different. I was talking
about GHC, as I think this is the kind of
concurrency people often use. Cooperative concurency is also useful
sometimes, but it is quite
a different beast.
-Iavor