Re: Proposal: split Chan and TChan into read and write ends

On Sat, Oct 27, 2012 at 6:59 AM, Ben Millwood wrote:

On Sat, Oct 27, 2012 at 4:23 AM, Brandon Simmons wrote:

...

I've implemented this already here: http://hackage.haskell.org/package/chan-split . 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: http://hackage.haskell.org/packages/archive/chan-split/0.5.0/doc/html/src/Co... 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. Brandon

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