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