In local.glasgow-haskell-users, you wrote:
That makes isEmptyChan essentially useless. Either it should be removed, or the implementation of Chan needs to be elaborated to support isEmptyChan.
I have a new implementation here which should track the number of elements in a channel, taking also into account unGetChan & dupChan. It seems to work, but lacks thorough testing. In any case, as it bloats the data structure
data Chan a = Chan (MVar ([MVar Integer],Stream a)) (MVar ([MVar Integer],Stream a)) (MVar Integer)
type Stream a = MVar ([MVar Integer],ChItem a)
it should probably be something like Control.Concurrent.CountChan.
Could you explain how this works? writeChan doesn't update the count - it should, right? But if it does, won't there be race conditions when read & write happen at the same time?
[although I consider mapM_ (uncurry putMVar) (zip counts (map (+1) vs)) rather neat :)]
Not as neat as zipWithM_ putMVar counts (map (+1) vs) :-p Cheers, Simon