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