std.algorithm (Was: dlang.org Library Reference)

[Andrei Alexandrescu]

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