On 2013-12-19 08:26, Meta wrote:

> Maybe it's not possible, I'm not well versed on how the compiler works.
> But I think that one module per algorithm may be too granular. Hasn't
> someone suggested splitting it up by category, e.g., sorting, mutation,
> searching, etc.?

Sounds more reasonable.

-- 
/Jacob Carlborg

On 2013-12-18 22:06, Andrei Alexandrescu wrote:
> http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
> for each module in phobos. Those include druntime dependencies.

What is this page, it takes 15 seconds to load the content.

-- 
/Jacob Carlborg

On Wednesday, 18 December 2013 at 21:40:08 UTC, Andrei Alexandrescu wrote:
> On 12/18/13 1:16 PM, Dmitry Olshansky wrote:
>> 19-Dec-2013 01:06, Andrei Alexandrescu пишет:
>>> http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
>>> for each module in phobos. Those include druntime dependencies.
>>>
>>
>> So the bill of using pretty much anything in Phobos is pulling in 87
>> modules. Pretty much what I feared it is.
>
> There are several directions we can take this.
>
> 1. Improve the compiler to handle imports lazily, i.e. an unused import is never opened. That's unlikely to help a lot of uses because most unqualified name lookups require all imports to be loaded (even after the name if resolved, the compiler must still look for ambiguities).
>
> 2. Push imports from top level into the entities (functions, classes etc) that use them.
>
> 3. Apply classic dependency management (break larger modules in smaller ones, accept some code duplication etc).
>
> I favor (2).
>
>
> Andrei

I suggested 2 a half a year ago - http://forum.dlang.org/thread/rrjaopnvapwhbatlsyvo@forum.dlang.org

One of the replys(http://forum.dlang.org/thread/rrjaopnvapwhbatlsyvo@forum.dlang.org#post-heaeasepzokrwdsvytbe:40forum.dlang.org) mentioned an issue(https://d.puremagic.com/issues/show_bug.cgi?id=7016) that blocks this solution.

On 19/12/13 13:55, Jacob Carlborg wrote:
> Sounds more reasonable.

Is there any reason why one couldn't have subpackages of packages, and so allow imports to be as fine-grained as the user wants?

  std.algorithm -> std.algorithm.sorting -> std.algorithm.sorting.quickSort ...

On Wednesday, 18 December 2013 at 21:48:14 UTC, Dmitry Olshansky wrote:
> 4. Split modules at least into a package of with at least 2 parts:
> - Meta (traits) - constraints, type definitions etc.
> - API - functions, globals and other "meat" of the module.

Yes, yes, yes. This could also help with encapsulation, since private works across module boundaries. The type listing only has minimal functions for its interface, then other functions are used, with UFCS, from the meat module.

On Thursday, 19 December 2013 at 13:20:30 UTC, Joseph Rushton Wakeling wrote:
> Is there any reason why one couldn't have subpackages of packages, and so allow imports to be as fine-grained as the user wants?

On the other hand, going too far might backfire, as more modules might lead to additional bloat with moduleinfo in the exe and more compile time cuz of more file loading/seeking.

I don't know if this will matter or not, but something we should test to know for sure.

On Thursday, 19 December 2013 at 13:00:04 UTC, Jacob Carlborg
wrote:
> On 2013-12-18 22:06, Andrei Alexandrescu wrote:
>> http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
>> for each module in phobos. Those include druntime dependencies.
>
> What is this page, it takes 15 seconds to load the content.

I noticed the same thing.  When I loaded the page I heard my disk
crank up and the computer working like crazy.  I was expecting
some magnificent graphical display, and then I got a list of 100
or so lines of plain text.

Maybe it uses the Javascript hypenator or something.  After all
it was Andrei that posted it :o)

Am Thu, 19 Dec 2013 10:56:19 +0100
schrieb Joseph Rushton Wakeling <joseph.wakeling@webdrake.net>:

> On 19/12/13 00:08, Walter Bright wrote:
> > 4. Break kitchen sink modules like std.algorithm into one module per algorithm. This should not result in code duplication.
> 
> That might be desirable for other purposes anyway (std.algorithm is big!), but how does this differ from the existing possibility of doing, e.g.,
> 
>      import std.algorithm : sort;

Selective imports are even slower than normal imports. You still have to load all of std.algorithm to find and disambiguate the symbol. Only when you split up the file physically it will reduce the compiler's workload.

-- 
Marco

On Thursday, 19 December 2013 at 07:26:54 UTC, Meta wrote:
> Maybe it's not possible, I'm not well versed on how the compiler works. But I think that one module per algorithm may be too granular. Hasn't someone suggested splitting it up by category, e.g., sorting, mutation, searching, etc.?

Previous discussions about this have come up with just using the categories already present in std.algorithm's documentation so it'd be:

std.algorithm.searching
std.algorithm.iteration
std.algorithm.sorting
std.algorithm.set
std.algorithm.mutation

Module tenses and exact naming could change, of course, but just those categories would break it up pretty evenly while keeping similar things close together.

Jonathan could probably give some guidance here because as far as I know he's the only person that has any experience attempting to break up a large phobos module into a package (std.datetime). I'm not sure what he has left or what blockers remain for finishing that up.

On 12/19/2013 04:13 PM, Craig Dillabaugh wrote:
> Maybe it uses the Javascript hypenator or something.  After all
> it was Andrei that posted it :o)

Hyphenate with D. http://code.dlang.org/packages/hyphenate
If someone would wire it up with http://code.dlang.org/packages/gumbo-d it could run on HTML files.