[Haskell-cafe] Relaxing atomicity of STM transactions

[Tom Hawkins]

Thanks for the responses, but I think I should explain a bit more.
I'm not interested in being able to read the live value of a TVar at
any arbitrary time (via. unsafeIOToSTM).  But rather I would like
looslyReadTVar to have exactly the same semantics as readTVar, except
that the STM runtime would not reject the transaction if the TVar is
modified by another transaction before the atomic commit takes place.

Also, as I would be implementing something similar in Atom, I'm not
necessarily interested in a Haskell implementation, but rather if the
programming experience is elevated by these alternative semantics.

For example:

incr :: TVar -> STM ()
incr a = looslyReadTVar a >>= writeTVar a . (+ 1)

decr a :: TVar -> STM ()
decr a = readTVar a >>= writeTVar a . (- 1)

If incr and decr where atomically started at the same time with the
same TVar, decr would be rejected if incr completed first, but not the
other way around.  The initial reaction may be that this seriously
breaks the atomicity of STM, but there may be cases where this could
be useful.  For instance, it allow a computationally expensive
transactions to complete, even if their inputs are constantly being
modified.  In the embedded domain, this could be a fault monitor that
reads a bunch of constantly changing sensors.

-Tom