Chris Okasaki wrote:
>
> > I'm with the option (B): negatives are just outside
> > the domain of take&drop, and should give you an error
> > message.
>
> For the people that share this sentiment, can you please
> explain why ints that are too big should not similarly
> give an error? I can see both being ok, or both being
> errors. I just don't see why one should be ok and the
> other an error.
How about a practical reason: if take has to check the length, it has to
scan the whole list to determine whether to return an error. This is
more strict (and more complex) than it should be. For example, if we
define take like this:
take n _ | n<0 = error "take: negative argument"
take n (x:xs) = x:(take (n-1) xs)
take 0 _ = []
take _ [] = error "take: list not long enough"
Then the error when n>(length l) is buried at the "end" of the list
returned by take. OTOH, a drop defined similarly would give an error
immediately if n>(length l). I don't like that asymmetry, do you? But
I definitely don't think negative values make sense for take & drop,
just as they are an error for (!!). I think we should be able to define
(!!) as
l !! n = head (drop n l)
...without worrying about what drop will do for negative arguments. A
negative index on a list should uniformly be an error. I just consider
take to mean "take at most" and drop to mean "drop at most".
I like:
take 3 (take 50 [1,2,3,4]) == [1,2,3]
By the way, replicate is defined in terms of take in the prelude, so
what do you think (replicate -1 x) should do?
Matt
