"S. Alexander Jacobson" wrote:
> The python behavior is:
> take n list | length list + n < 0 = []
> drop n list | length list + n < 0 = list
>
> I think this is the correct complement (dual?) of:
> take n list | length list - n < 0 = list
> drop n list | lenght list - n > 0 = []
> (the current behavior)
Yes, the python behavior above is the correct dual of the current behavior
of "take n" and "drop n" for n >= length list. And yes, your proposal for
the case n < 0 is consistent and sane as well (calling it insane is too
strong of a judgment for me). However, I do not think it is the *best*
choice among the sane and consistent proposals being offered. I would have
to agree with Fergus Henderson that it would be a very rare situation in
which you need to use "drop n xs" without knowing the sign of "n" ahead of
time *and* your proposed behavior for n < 0 is the desired one; and that
if you need a function that takes or drops from the end of a list then you
are surely better off to define a separate function to perform this operation,
not the least because having a different name makes it clear that its purpose
is different from that of the usual "take" or "drop".
Also, it is not accurate to say that your proposal simply amounts to con-
sidering "n" modulo "length xs" when n < 0. In fact this is only true for
length xs < n < 0. Your own example
> -3 -2 -1 0 1 2 3
> take "" "a" "ab" "abc" "a" "ab" "abc"
> drop "abc" "bc" "c" "" "bc" "c" ""
shows this clearly: take -3 "abc" /= take 0 "abc" and drop -3 "abc" /=
drop 0 "abc", even though -3 is congruent to 0 modulo the length of "abc".
My vote is for behavior (B): have "take n" and "drop n" fail if n < 0 in
all cases. I vote for this case because, as several others have already
pointed out, a negative value for "n" is most likely the result of a bug
that should be brought to someone's attention. And you can always define
functions "silent_take" and "silent_drop" that do not complain when
given a negative first argument if you need them. However, if behavior (A)
wins out, I won't complain very much. It's certainly a good second choice,
and one can even argue that mathematically it is the choice most consistent
with the current behavior for n >= 0 (this message is already getting long,
so I won't give the argument unless someone asks me to 8-) ).
As for "partition" and "splitAt", I agree with Simon's original proposals
(I am assuming that these are simply the official definitions of the
functions' behaviors, and that implementors are free to use other, more
efficient implementations that have exactly the same behavior, including
strictness behavior).
Mark
________________________________________________________________________________
Mark E. Hall
Mahanakorn University of Technology
Vanit Building 2, 8th Floor
1126/1 New Petchburi Road
Bangkok 10400, Thailand
66-2-6553181--7
[EMAIL PROTECTED]
http://www.mut.ac.th/~mehall
