[GHC] #3709: Data.Either.partitionEithers is not lazy enough

Duncan Coutts duncan.coutts at googlemail.com
Fri Dec 4 12:22:05 EST 2009


On Fri, 2009-12-04 at 01:19 +0000, Malcolm Wallace wrote:
> >>> No non-bottoming program
> >>> has changed, but fewer programs fail now. I find it hard to imagine
> >>> that anyone could have been relying on getting a crash here.
> >>
> >> Making something more lazy can cause a memory leak.

> To come back to the specifics of partitionEithers, is anyone arguing  
> that, in this case, the original over-strictness is either  
> intentional, or useful?

I don't think anyone is complaining about this specific case. I think we
agree that the general principle is to make things lazy except where
there are compelling reasons to do otherwise.

As another example, intersperse (and intercalate) could be made slightly
more lazy with no loss of efficiency (indeed it looks like it could be
an improvement):

intersperse :: a -> [a] -> [a]
intersperse _   []       = []
intersperse sep (x0:xs0) = x0 : go xs0
  where
    go []     = []
    go (x:xs) = sep : x : go xs

vs the standard def:

intersperse             :: a -> [a] -> [a]
intersperse sep []      =  []
intersperse sep [x]     =  [x]
intersperse sep (x:xs)  =  x : sep : intersperse sep xs


     intersperse '_' ('x' : undefined) = 'x' : undefined
vs
List.intersperse '_' ('x' : undefined) = undefined

Duncan



More information about the Libraries mailing list