Proposal: split Chan and TChan into read and write ends

[Brandon Simmons]

> On 10/27/12 12:28 PM, Johan Tibell wrote:
>> I think this makes for a great package or perhaps an extra
>> Unidirectional module nested inside the Chan module. Breaking the well
>> used Chan API doesn't seem necessary in this case.
>
> I agree. I like the idea, and I'd like to see it gain traction, but I'm
> not so keen on breaking the Chan/TChan API. Also, there seem to be some
> API issues to be ironed out (e.g., someone proposed
>
>      newBrodcastTChan :: STM (InTChan a, STM (OutTChan a))
>
> which has an obvious meaning, over
>
>      newInTChan :: STM (InTChan a)
>
> which is going to take some explaining.)

I assume you mixed those up? `newBroadcastTChan` naturally turns into
the (IMHO) much simpler `newInTChan` when the chan ends are split.

>
>
> It sounds like many people have implemented versions of this and
> uploaded them to Hackage already. Perhaps the best approach would be to
> (1) unify all those packages into a single "blessed" package, to reduce
> redundancy; (2) advertise that package as the way to go for new
> projects; (3) add it to the Platform if it gains traction; (4) maybe get
> around to deprecating the current Chan/TChan API some years down the
> road when it's no longer popular.

The best approach then for this route would be to go through the Chan
and TChan package and to turn it into a "split" version with minimum
edits (should only take a few minutes), perhaps changing a few names
where a better one obviously exists or the original no longer makes
sense (e.g. newBroadcastTChan). That way people can both see it's
correct, and easily port their code over.

I also wanted to link to in my original post, but couldn't find for
some reason, Leon P Smith's library:

    http://hackage.haskell.org/package/split-channel

It uses the name 'listen' for the equivalent function to the old
'dupTChan' which I think is an excellent choice.

Brandon