Proposal: Improve the API for TChan, TMVar, and TVar

Bas van Dijk v.dijk.bas at gmail.com
Sat Mar 26 12:26:46 CET 2011


On 26 March 2011 10:29, wren ng thornton <wren at freegeek.org> wrote:
>    tryReadTChan :: TChan a -> STM (Maybe a)

+1 if we also add:
tryReadChan :: Chan a -> IO (Maybe a)


>    peekTChan :: TChan a -> STM a
>    tryPeekTChan :: TChan a -> STM (Maybe a)

+1 if we also add:
peekChan :: Chan a -> IO a
tryPeekChan :: Chan a -> IO (Maybe a)


>    tryReadTMVar :: TMVar a -> STM (Maybe a)

+1 if we also add:
tryReadMVar :: MVar a -> IO (Maybe a)


>    modifyTVar :: TVar a -> (a -> a) -> STM ()
>    modifyTVar' :: TVar a -> (a -> a) -> STM ()

These are highly useful; I use them myself quite often. There's one
issue though that has always bugged me about the current API: The
types of modifyIORef and modifyMVar don't "line up":

modifyIORef :: IORef a -> (a -> a) -> IO ()
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b

It would have been nicer if modifyMVar lined up with modifyIORef:
modifyMVar :: MVar a -> (a -> a) -> IO ()

and have a separate:
modifyMVarM :: MVar a -> (a -> IO (a,b)) -> IO b

I guess it's difficult to change that at this stage.

but maybe we can add:

purelyModifyMVar :: MVar a -> (a -> a) -> IO () -- Note I don't like
this name at all...

Note that I'm in favor of adding:
modifyTVar :: TVar a -> (a -> a) -> STM ()

but do we also need to add:
modifyTVarM :: TVar a -> (a -> STM (a,b)) -> STM b

so that MVars and TVars have more consistent APIs?


>    swapTVar :: TVar a -> a -> STM a
+1


Thanks for the proposal!

Bas



More information about the Libraries mailing list