Unexpected foldAllP laziness

[Chris Reade]

I may have misunderstood, but I thought the monadic type for foldAllP was to protect against nested parallel evaluations.

That is why I expected this code to work without the explicit `seq` , but these are needed to avoid the "Performing nested parallel computation sequentially" problem.

writeHeatMapBMP :: String
                -> Array U DIM2 Double
                -> IO()
writeHeatMapBMP filename arr
  = do maxVal <- foldAllP max 0.0 arr
       minVal <- foldAllP min 0.0 arr
       arrImageOut <- minVal `seq` maxVal `seq`
                      computeP
                      $  R.map rgb8OfDouble
                      $  R.map (rampColorHotToCold minVal maxVal) arr
       writeImageToBMP filename arrImageOut

Is there a reason for not having the result of foldAllP forced?

[Ben Lippmeier]

Thanks for the report -- this looks like a bug to me. You should be able to work around it more cleanly by using bang patterns on all the bound variables:

writeHeatMapBMP !filename !arr
  = do !maxVal <- foldAllP max 0.0 arr
       !minVal <- foldAllP min 0.0 arr
       !arrImageOut <- computeP


                       $  R.map rgb8OfDouble
                       $  R.map (rampColorHotToCold minVal maxVal) arr
       writeImageToBMP filename arrImageOut


I just bangify everything out of habit how, which is why I hadn't noticed the missing `seq` for foldAllP.

Ben.