On 08/14/2011 01:29 PM, Jonathan M Davis wrote:
On Sunday, August 14, 2011 13:09:59 Timon Gehr wrote:
+1. Having take but not drop does not add to the beauty of the module.
I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile,
plus renaming std.algorithm.until to takeUntil. "until" is an
undescriptive name and it has a different meaning in functional
programming language libraries.
Renaming until takeUntil might be a good idea, though you'd have to talk
Andrei into it.
However, dropWhile isn't going to make it in because it's the same as find
except that predicate is reversed. All you have to do is use std.function.not
on your predicate to find, and you have dropWhile. The same goes for takeWhile,
except that it's std.algorithm.until which does the same thing aside from the
reversed predicate. And dropUntil _is_ find, no reversing of predicates
required.
I'd argue that find should actually have been called dropUntil. It is
not evident at all what find does, given the name alone. If it is called
dropUntil, nobody ever needs to read the documentation, be it the guy
who writes the code or the guy who has to read it. But as it is probably
heavily used, it is not sensible renaming it now. (and all I have to do
is define an alias :))
There was a fair bit of discussion about this in
https://github.com/D-Programming-Language/phobos/pull/147
Ok, thanks. However I don't agree that the functions would clutter the
standard library: In functional code, it is *crucial* for the
understandability and ease of writing of code that it is not necessary
to mess with predicates and it is possible to use a natural
nomenclature. As things are now, if somebody wants to write
functional-style D code, they have to implement a lot of the basic stuff
themselves.
The discussion is basically between keeping it small and orthogonal
(with imho questionable defaults) or making it large, flexible and
convenient, without requiring the user to implement many small helper
functions. I'm fine with defining my own utility functions, but I think
if many people end up writing that functionality themselves, the std
library has missed opportunities.
While I rather like the idea of having takeWhile and dropWhile, Andrei's
stance is that because they do the same thing as existing functions except for
the reversed predicate, they shouldn't be added. And while I'm not entirely
happy with that, I think that he has a very good point. We don't want to
clutter Phobos with functions which do the same things as other functions.
So, I could see an argument for renaming until to takeUntil. I don't know if
Andrei would go for that or not, but that could be reasonble. I certainly
agree that the name would be better. However, dropWhile, dropUntil, and
takeWhile aren't going to make it in because we already have functions which
already do the same thing with at most requiring that you reverse the
predicate.
drop, on the other hand, I'd argue adds much more value. You can't do drop
with any other function in Phobos. The closest that you get is Andrei's
suggestion of (popFrontN(range, n), range) which while clever, is fairly
hideous IMHO given that it uses the comma operator.
closer:
((int n){auto s=range.save(); popFrontN(s,n); return s}(n))
So, drop adds signicant
benefit towards a more functional style of programming, whereas the others just
make it so that you don't have to mess with your predicates as much to do what
you want - which would be nice but not nice enough to clutter the standard
library with.
- Jonathan M Davis
Yes, drop should be added. But I think that using the comma operator is
no more hideous than using something like:
until!(not!p1)(find!p2(range));
instead of
takeWhile!p1(dropUntil!p2)(range));
