The definition for “sub” does not work. The coefficients in the monomials left over at the end of the recursion, and those in the LT and GT branches need to be negated in order to get polynomial subtraction.

You can define sub properly with “sub x = add x . map (\(M c k) -> M (negate c) k)”. But if you do that, you might as well replace make “mergeBy” be the addition function, using the “+” operator instead of the merging function parameter.

The code I used was (sorry if this doesn’t get formatted correctly):

module Main
    where

import Control.Concurrent.Chan
import Control.Concurrent.Chan.Split

main = main1

payload :: [Integer]
payload = [1000000000000000.. 1000000010000000]

-- test traditional Chan implementation:
main0 = do
    putStrLn "Starting to write"
    s <- newChan
    mapM_ (writeChan s) payload
    putStrLn "Done"

main1 = do
    putStrLn "Starting to write"
    s <- newSendPort
    mapM_ (send s) payload
    putStrLn "Done"

No, I haven’t benchmarked. I find that surprising, but only a little bit. (I’m not surprised by being surprised at GHC optimizations.) It’s probably better to not rely on this particular optimization though, unless it’s a particularly well-understood and reliable optimization. I would expect it to be relatively easy to come up with use cases where the optimization doesn’t kick in, for reasons that may be less than immediately obvious.

I’m very interested in seeing your benchmark, though.

I certainly see the benefit to making it easier for the GC to do its duties, but I’m wondering if there are any cases where you’ve seen your implementation have better behavior then straight Chan with optimizations on.