[Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong?

[apfelmus]

Ryan Ingram wrote:
> No spooky-action-at-a-distance is possible.  David's more general
> "subatomically" primitive would achieve the same results; the proof is
> that
> (1) no side effects can be caused by the subatomic action, that is, no
> writes happen which could change future reads.
> (2) the result of the computation is ignored -except- for whether it
> retries or returns, that is, it can't affect the control flow of the
> rest of the transaction.
> 
> So, if have a transaction T that is waiting inside "retry" for a
> variable that it read to change, and a variable that is only accessed
> in a "subatomic" part of T is changed, we can try running the
> subatomic computation first.  Here are the four cases:
> 
> 1) The subatomic computation succeeded before and still succeeded.
> Then we know the end result of the computation is unaffected, and will
> still retry.  No need to do anything.
> 2) The subatomic computation succeeded before and now fails (calls
> 'retry' or retryRO').  Then we know that the computation will now fail
> at this earlier point.  Mark the change to "fail" in the transaction
> log and leave the computation in the "waiting for retry" state.
> 3) The subatomic computation failed before and still fails.  See (1)
> 4) The subatomic computation failed before and now succeeds.  The
> result of the entire computation can change, we should now re-run the
> entire computation.

Sounds good. But I wonder what "obscure" optimization comes next; can we 
have a toy-model of STM? I mean, it should be possible to express both 
the "continuation-logging" and "read-only-fail" optimization in terms of

   type STM a = Maybe a

or similar?


Regards,
apfelmus