parBufferWHNF could be less subtle

[duncan]

I would suggest modifying parBufferWHNF as follows, with the {- x seq -} actually included.

parBufferWHNF :: Int -> Strategy [a]
parBufferWHNF n0 xs0 = return (ret xs0 (start n0 xs0))
  where -- ret :: [a] -> [a] -> [a]
    ret (x:xs) (y:ys) = y `par` (x : ({-x `seq`-} ret xs ys))
    ret xs     _      = xs

    -- start :: Int -> [a] -> [a]
    start 0   ys     = ys
    start !_n []     = []
    start !n  (y:ys) = y `par` start (n-1) ys

The point of the extra x seq is so that consumers that do not evaluate the list element before evaluating the next cons cell don't get such surprising loss of parallelism. For example non-strict left folds like sum will rush to the end of the list spine without evaluating the list elements, and then evaluate the elements later. That does not work well with the parBufferWHNF strategy. Adding the extra seq fixes it. Note that in this case I think seq or pseq would work.

[igloo]

Does that make more sense than

y `par` (x `seq` (x : ret xs ys))

?

[simonmar]

The fix is slightly odd, because it makes parBufferWHNF strict in the list elements. We'd have to update the generic parBuffer to be strict in the list elements too, for consistency.

Arguably further sparks should be created by demand for the elements, not the spine. Wouldn't this work?

    ret (x:xs) (y:ys) = (y `par` x) : ret xs ys

[igloo]

Duncan, do you think you would be able to lead the way to working out what the best fix for this ticket is, please?