Proposal: split Chan and TChan into read and write ends

Brandon Simmons brandon.m.simmons at
Sat Oct 27 17:47:21 CEST 2012

On Sat, Oct 27, 2012 at 6:59 AM, Ben Millwood <haskell at> wrote:
> On Sat, Oct 27, 2012 at 4:23 AM, Brandon Simmons
> <brandon.m.simmons at> wrote:
>> I've implemented this already here:
>> . You can ignore the
>> type classes I've defined; they're there for my own reasons and not
>> part of the proposal.
> So what's the complete API that we're discussing here? I think the
> /idea/ is great, but it doesn't feel like a concrete proposal until we
> have a list of type signatures, so we can discuss the details like
> whether or not `dupChan` is a good name for that operation (my
> instinct is that it sounds pretty much the same as `cloneChan`, and
> it's going to be hard to remember the difference).

Good point, sorry. Here's what the API for TChan looks like after
doing the mechanical transformations into split form (I'm not wedded
to these names):

newSplitTChan :: STM (InTChan a, OutTChan a)
newSplitTChanIO :: IO (InTChan a, OutTChan a)
-- this is 'newBroadcastTChan' with a more appropriate name:
newInTChan :: STM (InTChan a)
newInTChanIO :: IO (InTChan a)
writeTChan :: InTChan a -> a -> STM ()
readTChan :: OutTChan a -> STM a
peekTChan :: OutTChan a -> STM a
tryPeekTChan :: OutTChan a -> STM (Maybe a)
tryReadTChan :: OutTChan a -> STM (Maybe a)
isEmptyTChan :: OutTChan a -> STM Bool
unGetTChan :: OutTChan a -> a -> STM ()
dupTChan :: InTChan a -> STM (OutTChan a)
cloneTChan :: OutTChan a -> STM (OutTChan a)

If you want to look at implementation, see:

If it would be more helpful for me to provide a proper patch with the
bare minimum modifications, I'd be happy to when I get a moment.


> I think my preferred signature for `newBroadcastTChan` would be `STM
> (InTChan a, STM (OutTChan a))` or something similar. Then `dupChan`
> might be unnecessary.

More information about the Libraries mailing list