> Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
> > (A) Make them defined for any n. If n < 0, do something reasonable:
> > take: give empty list
> > drop: give whole list
> >
> > (B) Make them defined for n > length xs, but fail for n < 0.
I vote for (B).
'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> S. Alexander Jacobson <[EMAIL PROTECTED]> wrote:
>
> > Why not do what python does?
> >
> > drop -2 -- drops the last 2 elements from the list
> > take -2 -- grabs the last 2 elements from the list
>
> Please no.
>
> I hate the design used in the K language: when thinking how to name a
> function, find an existing function name which in all or almost all
> current meanings use a disjoint domain of arguments, and reuse that
> name. Here it is not as extreme as in K, but IMHO still not nice.
Here, here.
If you want that behaviour, don't extend the meaning of the existing
take and drop functions, instead define new functions
take_from_end n l = drop ((length l) - n) l
drop_from_end n l = take ((length l) - n) l
and use those.
> Overloading take and drop would make sense when the decision about
> how to proceed would be often done at a different place than the
> usage of these functions, i.e. when the overloaded function was used
> polymorphically. I think it's not the case.
I agree. Almost invariably you want to take or drop from a
particular end of the list, not from a runtime-determined end.
In that case, it is better to say what you mean, by using
`drop' if you want to drop from the front of the list,
and `drop_from_end' if you want to drop from the back of the list.
Defining `drop' for negative arguments to mean `drop_from_end'
would make code more difficult to read, since I can't tell from
the function name which end the values are being dropped from.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
