On Thursday, 19 December 2013 at 00:15:12 UTC, Justin Whear wrote:
> Presumably there would still be a std.algorithm package module;
>  the
> questions is: does
>   import std.algorithm : joiner;
> still work if std.algorithm is actually a package module and joiner is in
> a std.algorithm.joiner module?

Intended to work by matching DIP.

On Wednesday, 18 December 2013 at 23:51:06 UTC, Meta wrote:
> Of course, another large boon would be to correct the implementation of:
>
> import std.algorithm: sort, find, splitter, swap;
>
> So that it actually works in a sane way as opposed to pulling in everything.

I don't see how it is even theoretically possible. You still need to lex/parse whole file to locate needed symbols (and semantic phases are already lazy in most cases afaik)

On 2013-12-18 22:40, Andrei Alexandrescu wrote:

> 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).

I would guess that not a single of these solutions alone would solve the problem. Most likely all will be needed.

-- 
/Jacob Carlborg

On Thursday, 19 December 2013 at 00:23:47 UTC, Dicebot wrote:
> On Wednesday, 18 December 2013 at 23:51:06 UTC, Meta wrote:
>> Of course, another large boon would be to correct the implementation of:
>>
>> import std.algorithm: sort, find, splitter, swap;
>>
>> So that it actually works in a sane way as opposed to pulling in everything.
>
> I don't see how it is even theoretically possible. You still need to lex/parse whole file to locate needed symbols (and semantic phases are already lazy in most cases afaik)

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.?

On 12/19/13, Meta <jared771@gmail.com> wrote:
> For example, when you want to use sort, find, splitter and swap all together, you either have the choice of doing:
>
> import std.algorithm;
>
> And pull in everything, or doing:
>
> import std.algorithm.sort, std.algorithm.find, std.algorithm.splitter, std.algorithm.swap;
>
> Or is there something I'm missing here?

Hopefully we would add a feature that implements selective module imports, e.g.:

// either a symbol in the algorithm.d/package.d module or
// another module in the algorithm package *if* std.algorithm is a package.
import std.algorithm : sort;

I think there's a bugzilla enhancement for this.

On 18/12/13 22:40, Andrei Alexandrescu wrote:
> 2. Push imports from top level into the entities (functions, classes etc) that
> use them.

This is probably going to be very productive.  Example: a while back we had a discussion about how std.stdio wound up pulling in std.complex.  John Colvin worked out that the module dependency goes something like this:

     std.stdio -> std.algorithm -> std.random -> std.numeric -> std.complex

... so I looked a bit deeper and found that there are at least 2 points where that dependency chain could be broken:

   * std.algorithm relies on std.random I think only one actual function, namely
     topN (where it calls std.random.uniform).  All other uses of std.random are
     inside unittests.
        (Incidentally it's a bit bad that topN makes use of randomness but
         does not AFAICS allow you to specify a RNG.)

   * std.numeric relies on std.complex for quite a few functions and objects,
     but by no means all, and I doubt that std.random's dependency on
     std.numeric makes use of any of those.  The problem here is that those
     functions need awareness of std.complex.Complex at the module level, e.g.
     because they have Complex return-types.  So, it might be productive to
     separate out std.numeric based on std.complex dependency.

I can provide a patch for std.random very easily (I already have it un-committed on my system right now as a result of re-running the above analysis).

I also think it should be policy for Phobos that if an import is required only for unittests, it must be imported in those individual unittests, not for the module as a whole (and not in a version(unittest) block, which would disguise the problem and cause failures between unittest release builds vs. release builds).

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;

On 2013-12-19 10:56, Joseph Rushton Wakeling wrote:
> 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;

Your line of code imports all of std.algorithm, as well as all modules imported by std.algorithm, etc. This includes functions used by topN, largestPartialIntersectionWeighted, findSplit, and so on.

A modularized std.algorithm.sort would only import what sort needs (and what sort's needs need, and so on, but likely a much small graph).

"But why can't we make the compiler smrter, so import std.algorithm : sort; only imports what's needed?" you might ask. I believe it's already been covered in this thread: overloads, for one (knowledge of all overloads is required). Second, if an imported type is used, how should the compiler guess which module contains the type? There may be more reasons, too.

--
  Simen

On 2013-12-18 22:19:14 +0000, H. S. Teoh said:

> I've been saying this over and over: now we have package.d, let's make
> use of it. Jonathan has been working on splitting up std.datetime
> (though that has yet to materialize); I think std.algorithm and
> std.range are due, too.

+1 on this.   When I have some time I was going to make a pull request on some of the modules.

-Shammah

On 19/12/13 12:33, Simen Kjærås wrote:
> Your line of code imports all of std.algorithm, as well as all modules imported
> by std.algorithm, etc. This includes functions used by topN,
> largestPartialIntersectionWeighted, findSplit, and so on.

Ah, OK.  Thanks for the clarification.  A shame, but understandable.