On 2012-12-22 18:53, Sönke Ludwig wrote:

> In the latest upload a number of items is addressed:
>   - vertical margins at the top
>   - redundant column headers
>   - +/- signs for the package tree
>   - jumps to line numbers on github (which are off because of changes after the release)
>   - some macro processing fixes (e.g. std.array.popBack contained some bad HTML because of this)
>   - also moved the authors/license sections to the bottom to see how it looks

I'm looking at this page:

http://vibed.org/temp/d-programming-language.org/phobos/std/net/isemail/EmailStatusCode.html

I think it would be better if there was more space for the Name column and let the Description column automatically wrap. It's better that the description uses multiple rows than the symbol names.

-- 
/Jacob Carlborg

On 2012-12-22 17:15, Andrei Alexandrescu wrote:

> Looks great! I think that belongs in an index page (which doesn't exist
> yet, though we do define a sitemap http://dlang.org/sitemap.html).

The sitemap is a bit different. The list of symbols could be the index page or a part of the index page for the reference documentation, that is, this page:

http://dlang.org/phobos/index.html

-- 
/Jacob Carlborg

On Sunday, 23 December 2012 at 13:21:16 UTC, Andrei Alexandrescu wrote:
> On 12/23/12 6:44 AM, foobar wrote:
>> Using an all encompassing "algorithms" module is also unhelpful as all
>> code is essentially an algorithm to accomplish some task. This is akin
>> to opening a store called - "A store" or perhaps "A place to sell you
>> stuff".
>
> That I disagree with a bit. I think it's rather clear that std.algorithm includes classic, consecrated algorithms the kind you'll find in a book entitled "Algorithms". By your argument a book called "Algorithms" would not make sense because it would need to describe the entire computing world.
>
> So if I'm looking for sort, I'd open "algorithm". If I'm looking for parsing program options, I wouldn't expect it to be in the same place.
>
>> As a client of said shop, I want a better description if I to buy at the
>> shop. Even a general "Clothes shop" is already much better. For 3rd
>> party it also often makes sense to have a brand name - e.g we all know
>> what "vibe.d" is all about.
>
> Such differentiation is also useful.
>
>
> Andrei

Does it mean you agree with the rest? :)

Regarding std.algorithm, the module isn't called - 'classic, consecrated algorithms the kind you'll find in a book entitled "Algorithms"'. It is simply called 'std.algorithm' and there are many, *many* books on algorithms. Should this module include concurrent algorithms? Should it include distributed algorithms? Should it include statistic algorithms? Should it include natural language processing algorithms? Should it include genetic algorithms? I think it's clear by now that the name does not convey what you intend it to convey.

A much better and more user friendly scheme would be to classify the algorithms by their *functionality* and not by some undefined "belongs to classical algorithms books" relation.
e.g. "Sorting algorithms", "Set operations", etc.
Now, if I want to sort something I know to "shop" at the "sorting algorithms" outlet and don't need to spend time going over a potentially infinite list of algorithms.

On 12/23/12 9:08 AM, foobar wrote:
> Regarding std.algorithm, the module isn't called - 'classic, consecrated
> algorithms the kind you'll find in a book entitled "Algorithms"'. It is
> simply called 'std.algorithm' and there are many, *many* books on
> algorithms. Should this module include concurrent algorithms? Should it
> include distributed algorithms? Should it include statistic algorithms?
> Should it include natural language processing algorithms? Should it
> include genetic algorithms? I think it's clear by now that the name does
> not convey what you intend it to convey.

Importing std.container doesn't mean all containers conceivable will be there, and so on. Sense and sensibility must always be exercised.

> A much better and more user friendly scheme would be to classify the
> algorithms by their *functionality* and not by some undefined "belongs
> to classical algorithms books" relation.
> e.g. "Sorting algorithms", "Set operations", etc.
> Now, if I want to sort something I know to "shop" at the "sorting
> algorithms" outlet and don't need to spend time going over a potentially
> infinite list of algorithms.

I like std.algorithm the way it is.


Andrei

On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu wrote:
> On 12/23/12 9:08 AM, foobar wrote:
>> Regarding std.algorithm, the module isn't called - 'classic, consecrated
>> algorithms the kind you'll find in a book entitled "Algorithms"'. It is
>> simply called 'std.algorithm' and there are many, *many* books on
>> algorithms. Should this module include concurrent algorithms? Should it
>> include distributed algorithms? Should it include statistic algorithms?
>> Should it include natural language processing algorithms? Should it
>> include genetic algorithms? I think it's clear by now that the name does
>> not convey what you intend it to convey.
>
> Importing std.container doesn't mean all containers conceivable will be there, and so on. Sense and sensibility must always be exercised.
>
>> A much better and more user friendly scheme would be to classify the
>> algorithms by their *functionality* and not by some undefined "belongs
>> to classical algorithms books" relation.
>> e.g. "Sorting algorithms", "Set operations", etc.
>> Now, if I want to sort something I know to "shop" at the "sorting
>> algorithms" outlet and don't need to spend time going over a potentially
>> infinite list of algorithms.
>
> I like std.algorithm the way it is.
>
>
> Andrei

On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu
wrote:
> On 12/23/12 9:08 AM, foobar wrote:
>> Regarding std.algorithm, the module isn't called - 'classic, consecrated
>> algorithms the kind you'll find in a book entitled "Algorithms"'. It is
>> simply called 'std.algorithm' and there are many, *many* books on
>> algorithms. Should this module include concurrent algorithms? Should it
>> include distributed algorithms? Should it include statistic algorithms?
>> Should it include natural language processing algorithms? Should it
>> include genetic algorithms? I think it's clear by now that the name does
>> not convey what you intend it to convey.
>
> Importing std.container doesn't mean all containers conceivable will be there, and so on. Sense and sensibility must always be exercised.
>
>> A much better and more user friendly scheme would be to classify the
>> algorithms by their *functionality* and not by some undefined "belongs
>> to classical algorithms books" relation.
>> e.g. "Sorting algorithms", "Set operations", etc.
>> Now, if I want to sort something I know to "shop" at the "sorting
>> algorithms" outlet and don't need to spend time going over a potentially
>> infinite list of algorithms.
>
> 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.

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?

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.

2. The set algorithms should be in their own module. They are rarely used and quite specific in what they do.

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.

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?

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

Am 23.12.2012 14:52, schrieb Jacob Carlborg:
> On 2012-12-22 18:53, Sönke Ludwig wrote:
> 
>>   - jumps to line numbers on github (which are off because of changes after the release)
> 
> Can you lock it to the same hash that the docs are generated from?
> 

I've locked it to the v2.060 tag now, but as far as I can see github also allows to brows arbitrary hashes, so this shouldn't be a problem.

Am 23.12.2012 14:58, schrieb Jacob Carlborg:
> I think it would be better if there was more space for the Name column and let the Description column automatically wrap. It's better that the description uses multiple rows than the symbol names.
> 

I changed the first column from "width: 150pt;" to "min-width: 170pt". It can still wrap, but the two columns can now freely fight for the space if they need to.

On Sunday, December 23, 2012 18:54:15 Peter Alexander wrote:
> Would it be possible to split the library up and add public imports to std.algorithm of the moved symbols?

DIPs 15 and 16 relate to the ability to split up a module into separate modules within a package with the same name without breaking code. If something along those lines were implemented, it would potentially make some sense to reorganize std.algorithm as a package. I'd definitely break up std.datetime if something like that were implemented, but someone has to do it. I started looking into it at one point, but I have far higher priorities right now, so I didn't get very far and don't have time to tackle it right now.

- Jonathan M Davis