inits

[Chris Kuklewicz]

Aaron Denney wrote:
> On 2006-04-08, Chris Kuklewicz <haskell at list.mightyreason.com> 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