I have proposed[1] the replacement of the atomicModifyMutVar# primop, and the addition of two cheaper but less capable ones. It seems likely that the proposal will succeed, but that the GHC steering committee will leave the question of user interface changes to the libraries list. I would like to open the discussion here. The new primops lead naturally to several thin wrappers: -- Atomically replace the IORef contents -- with the first component of the result of -- applying the function to the old contents. -- Return the old value and the result of -- applying the function, without forcing the latter. -- -- atomicModifyIORef ref f = do -- (_old, ~(_new, res)) <- atomicModifyIORef2Lazy ref f -- return res atomicModifyIORef2Lazy :: IORef a -> (a -> (a, b)) -> IO (a, (a, b)) -- Atomically replace the IORef contents -- with the result of applying the function -- to the old contents. Return the old and -- new contents without forcing the latter. atomicModifyIORefLazy_ :: IORef a -> (a -> a) -> IO (a, a) -- Atomically replace the IORef contents -- with the given value and return the old -- contents. -- -- atomicWriteIORef ref x = void (atomicSwapIORef ref x) atomicSwapIORef :: IORef a -> a -> IO a Based on the code I've read that uses atomicModifyIORef, I believe that the complete laziness of atomicModifyIORef2Lazy and atomicModifyIORefLazy_ is very rarely desirable. I therefore believe we should also (or perhaps instead?) offer stricter versions: atomicModifyIORef2 :: IORef a -> (a -> (a, b)) -> IO (a, (a, b)) atomicModifyIORef2 ref f = do r@(_old, (_new, _res)) <- atomicModifyIORef2Lazy ref f return r atomicModifyIORef_ :: IORef a -> (a -> a) -> IO (a, a) atomicModifyIORef_ ref f = do r@(_old, !_new) <- atomicModifyIORefLazy_ ref f return r The classic atomicModifyIORef also admits a less gratuitously lazy version: atomicModifyIORefNGL :: IORef a -> (a -> (a,b)) -> IO b atomicModifyIORefNGL ref f = do (_old, (_new, res)) <- atomicModifyIORef2 ref f return res Should we add that as well (with a better name)? Should we even consider *replacing* the current atomicModifyIORef with that version? That could theoretically break existing code, but I suspect it would do so very rarely. If we don't change the existing atomicModifyIORef now, I think we should consider deprecating it: it's very easy to accidentally use it too lazily.