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

[Bas van Dijk]

On 26 March 2011 22:02, wren ng thornton <wren at freegeek.org> wrote:
> On 3/26/11 7:26 AM, Bas van Dijk wrote:
>>
>> On 26 March 2011 10:29, wren ng thornton<wren at freegeek.org>  wrote:
>>>
>>>    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.
>
> Perhaps the solution at this stage would be to:
>
> (1) add modifyMVarM :: MVar a -> (a -> IO (a,b)) -> IO b
> (2) deprecate modifyMVar
> (3) wait a cycle
> (4) remove modifyMVar (if needed)
> (5) wait a cycle (if needed)
> (6) add modifyMVar :: MVar a -> (a -> a) -> IO ()
>
> It'll take forever, but I think it's important to get the names right for
> this kind of thing rather than letting the inconsistency linger. Of course,
> this would best be done through a separate proposal IMO.

I agree this should be done in a separate proposal. But while we're
talking about it: what's the reason for the extra wait cycle in (5)?
Can't we just replace (4),(5) and (6) with a single point where we
undeprecate modifyMVar and change its type to the final: MVar a -> (a
-> a) -> IO () ?

Bas