On 12/23/12 12:54 PM, Peter Alexander wrote:
On Sunday, 23 December 2012 at 16:06:57 UTC, John Colvin wrote:
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu wrote:
I like std.algorithm the way it is.
Andrei
Same here. In my mind it's about generality:
General purpose algorithms (sort, partition etc.) belong in
std.algorithm and more specific algorithms belong in their own
appropriately named modules.
Levenshtein distance is general purpose?
There's always stuff on the fringes that could be debated one way or
another.
I'm not too fussed about std.algorithm, but I think it could be better.
Here's some criticisms I have:
1. The iteration algorithms should be std.range. I find it confusing
that (for example) joiner and chain are in different modules when they
are so similar.
I agree, but then I guess it's not too bad the way it is.
2. The set algorithms should be in their own module. They are rarely
used and quite specific in what they do.
But then there's stuff such as group that is set-oriented yet quite
useful in general.
3. The sorting algorithms should be in their own module. There are many
different sorting algorithms that could be added, and if they stay in
std.algorithm then it is going to get quite bloated.
I guess. But then approaches could be implemented as policies to sort etc.
Interestingly, EASTL also decided to split C++'s <algorithm> into
sorting, set, and heap components. I think this is the right thing to do.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
My main worry is that std.algorithm becomes std.miscellaneous -- a place
where things go when you can't think where else to put them. The reason
this happens is because of the name. As someone mentioned earlier, just
about every function implements an "algorithm" of some sort, so people
can feel justified in putting everything in std.algorithm. Heck, if
"min" is an "algorithm" then anything is!
Would it be possible to split the library up and add public imports to
std.algorithm of the moved symbols?
To be frank, I look at the problems D is facing right now and really the
(re)organization of std.algorithm is nowhere near the top of the list.
If we were a perfectly efficient forum, we wouldn't be discussing it now
at all.
Andrei
