Proposal: split Chan and TChan into read and write ends

Jeff Shaw shawjef3 at gmail.com
Sat Oct 27 19:51:41 CEST 2012


I had a similar idea earlier this year, and uploaded this package:

http://hackage.haskell.org/package/privileged-concurrency

Jeff

On 10/27/2012 11:47 AM, Brandon Simmons wrote:
> On Sat, Oct 27, 2012 at 6:59 AM, Ben Millwood <haskell at benmachine.co.uk> wrote:
>> On Sat, Oct 27, 2012 at 4:23 AM, Brandon Simmons
>> <brandon.m.simmons at gmail.com> 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/Control-Concurrent-STM-TChan-Split.html
>
> 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.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries




More information about the Libraries mailing list