On Tue, Sep 28, 2010 at 8:54 AM, Felipe Lessa wrote:

On Tue, Sep 28, 2010 at 10:41 AM, Peter Robinson wrote:

...

readTVarIO :: TVar a -> IO a

One needs to know if it is ok to wrap this IO action into an STM action.  For example,

...

data I a = I a

looselyReadTVar :: TVar a -> STM a looselyReadTVar tvar =   let v = unsafePerformIO (I <$> readTVarIO tvar)   in case v of I x -> return x

The 'case' is needed because otherwise the TVar would be read only when its value was requested, and we want to keep the ordering.  The 'I' datatype is used to avoid evaluating the user's value (which could even be 'undefined').

Note that this function can be used on any monad, but I don't think that is a good idea =).

Cheers!

Isn't there an 'unsafeIOToSTM' function somewhere? Something like:

unsafeIOToSTM (IO k) = STM k

Then you might not need the case statement. Antoine

On Tue, Sep 28, 2010 at 9:05 AM, Felipe Lessa wrote:

On Tue, Sep 28, 2010 at 11:01 AM, Antoine Latter wrote:

...

Isn't there an 'unsafeIOToSTM' function somewhere? Something like:

...

unsafeIOToSTM (IO k) = STM k

Then you might not need the case statement.

I thought there was, but I couldn't find it in the 'stm' package [1], using Hoogle [2] nor using Hayoo [3].

Funny - I had the module open in another window as I wrote my response. It's in GHC.Conc[1]:

unsafeIOToSTM :: IO a -> STM a

defined as I had guessed. Antoine [1] http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/GHC-Conc....

2010/9/29 Tom Hawkins :

In the embedded domain, this could be a fault monitor that reads a bunch of constantly changing sensors.

I think that sensor reading belongs to IO, not STM.

Clojure has a commute operator whose semantics seem appropriate to your concerns: http://clojure.org/refs http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/comm... Commute in haskell would be roughly :: TVar a -> (a -> a) -> STM a. The TVar touched by commute does not get marked such that the transaction could retry. Nor is the TVar itself even updated at the time. Rather, it is read, and the result of applying some transform to it is returned. Then, when the transaction commits, the tvar is atomically modified by the function and actually updated. This works if the operation commutes with all other operations performed on the TVar anywhere else that may be running concurrently, and if no essential use (i.e. requiring atomicity) is made of the value returned from commute. Both properties can only be enforced by the discipline of the programmer. I don't know how much discussion there's been in the Clojure community about the utility of commute, as a quick google mainly reveals people trying to either figure it out or explain it. Cheers, Sterl. On Sep 28, 2010, at 7:36 PM, Tom Hawkins wrote:

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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe