Optimizations for mutable structures?

[Claus Reinke]

|>>    - Fetch elimination for imperative reads:
|>>      writeIORef r e >> acts >> readIORef r
|>>  === writeIORef r e >> acts >> return e
|> 
|> This transformation is valid only on single-threaded systems.
|> If there is any possibility of an IORef being shared across threads,
|> you are out of luck.
|
|(assuming 'acts' doesn't modify 'r').

this remark is the problem.

|No, Jan's transformation is correct even in a multithreaded setting.  It
|might eliminate some possible outcomes from a non-deterministic program,
|but that's ok.  There's no requirement that all interleavings according
|to the semantics have to be implemented. ..

not implementing traces promised as possible by the semantics is not 
a good idea, imho, as programmers have some control over the set of 
traces themselves. 

in this case, acts could implement the synchronisation with another 
thread working on r, ie., even if acts does not modify r itself, it might
reliably cause another thread to modify r before acts can end. if such 
synchronisations depend on traces you have eliminated, the code 
would just block (without apparent reason), whereas in this case, r 
will have a value after acts that shouldn't have been possible, due 
to the explicit synchronisation code (again, happy debugging) ..

of course, you could try to infer non-sequential interference with r
resulting from act, but that is what Malcolm pointed out - you have
to take the full semantics into account when doing such transformations
(btw, java originally made a mess of this- hope that has been fixed by now).

cheers,
claus