
Aaron Denney wrote:
On 2006-04-08, Chris Kuklewicz
wrote: Is the head of the inits of undefined really an error? Since the head of inits [] is also [] ... But if you really want that undefined to produce an error.. you could just : inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn inits' _ = undefined
Exactly. Now inits' *is* a drop in replacement for inits.
Right, but the new spiffy inits seems to be a strict superset. Does anything plausibly depend on the strictness of the original. I think it was written that way for clarity, not for the strictness properties.
I have nothing that depends on the difference. And it really only affects (inits undefined). There is a certain progressions to this though (A) inits undefined is undefined (B) inits [undefined] is []:[undefined] (C) inits [1,undefined] is []:[1]:[1,undefined] The original replacement made (A) behave like (B), which breaks the nice progression. -- Chris