On Saturday, 21 December 2013 at 21:38:59 UTC, Dmitry Olshansky wrote:
> As it stands the only thing lazy buys us is "pay as you touch" contrary to "pay as you name the intent to touch". The problem is that the payment is for the whole stock of the said "shop". I see second problem (granularity of imports) as far more critical then the first (condition under which the pieces are imported). The second problem seems solvable within the current implementation, the first seems like it would need arbitrary amount of time to fix and gains are marginal.

We should also keep in mind that as we split up modules and split apart dependencies, it also means that *as* we import a specific package, we are increasing our "use/import" ratio, further diminishing the issue of "import things we don't need." (who would import "std.foo.bar.baz", if they weren't planning to use baz?).

Arguably, we'd get "quadratic" effectiveness ;)

22-Dec-2013 02:16, monarch_dodra пишет:
> On Saturday, 21 December 2013 at 21:38:59 UTC, Dmitry Olshansky wrote:
>> As it stands the only thing lazy buys us is "pay as you touch"
>> contrary to "pay as you name the intent to touch". The problem is that
>> the payment is for the whole stock of the said "shop". I see second
>> problem (granularity of imports) as far more critical then the first
>> (condition under which the pieces are imported). The second problem
>> seems solvable within the current implementation, the first seems like
>> it would need arbitrary amount of time to fix and gains are marginal.
>
> We should also keep in mind that as we split up modules and split apart
> dependencies, it also means that *as* we import a specific package, we
> are increasing our "use/import" ratio, further diminishing the issue of
> "import things we don't need." (who would import "std.foo.bar.baz", if
> they weren't planning to use baz?).

The main gain is to the library code be it Phobos itself or any 3rd party code. Application code is import-happy by definition and only few folks at this level would care to import things in such a fine garined manner.

>
> Arguably, we'd get "quadratic" effectiveness ;)

In mind the constant factor is increasing (as in more files, more syscalls) but as the total LOCs per package version of a module stays the same I fail to see any substantial efficiency loss.

-- 
Dmitry Olshansky

On 12/21/13 1:38 PM, Dmitry Olshansky wrote:
> As it stands the only thing lazy buys us is "pay as you touch" contrary
> to "pay as you name the intent to touch". The problem is that the
> payment is for the whole stock of the said "shop". I see second problem
> (granularity of imports) as far more critical then the first (condition
> under which the pieces are imported). The second problem seems solvable
> within the current implementation, the first seems like it would need
> arbitrary amount of time to fix and gains are marginal.

The way I see it is we can improve the compilation speed for everyone without having them change the code in any way, as opposed to toiling over phobos to the benefit of nothing else but phobos. Which is the better win?

Andrei

22-Dec-2013 08:23, Andrei Alexandrescu пишет:
> On 12/21/13 1:38 PM, Dmitry Olshansky wrote:
>> As it stands the only thing lazy buys us is "pay as you touch" contrary
>> to "pay as you name the intent to touch". The problem is that the
>> payment is for the whole stock of the said "shop". I see second problem
>> (granularity of imports) as far more critical then the first (condition
>> under which the pieces are imported). The second problem seems solvable
>> within the current implementation, the first seems like it would need
>> arbitrary amount of time to fix and gains are marginal.
>
> The way I see it is we can improve the compilation speed for everyone
> without having them change the code in any way, as opposed to toiling
> over phobos to the benefit of nothing else but phobos.

Because of poor organization of Phobos we have to. Anyhow work on std library is a major benefit to everyone who uses it (including compilation speed). And nobody have to change code to get the benefits e.g. the proverbial size of hello world is going to be smaller (you surely recall that recent problem).

Unlike Phobos many projects already have sane package structure but the moment they use this tiny primitive (e.g. writeln) in Phobos compile times drop.

> Which is the
> better win?

I'd take both :o)

I'm not against lazy imports per see. The problem is that the "instant" benefit is going to be smaller then you seem to imply. I'd like to be proven otherwise but there is no experimental compiler to see yet.

If Phobos stays pretty much as is lazy imports is just a new (potentially slow and bogus) feature. And we know how new stuff works - see -allinst switch. On the other hand restructuring Phobos is a bonus that users don't have to suffer for.

-- 
Dmitry Olshansky

On Saturday, 21 December 2013 at 22:16:13 UTC, monarch_dodra wrote:
> We should also keep in mind that as we split up modules and split apart dependencies, it also means that *as* we import a specific package, we are increasing our "use/import" ratio, further diminishing the issue of "import things we don't need." (who would import "std.foo.bar.baz", if they weren't planning to use baz?).
>
> Arguably, we'd get "quadratic" effectiveness ;)

I agree: I would be happy to have a warning for a module import when any of its symbols is used.
That would lead to cleanup in our code...

/Paolo

Am Sat, 21 Dec 2013 22:43:58 +0100
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> I could think of more optimizations, for example if we had a way of exporting a list of module-level symbols into some kind of intermediary format (say JSON), the compiler could look up this list rather than to have to eagerly load every module in search of a symbol.

We have .di files already, which could cut on the amount of parsing required.

Other than that your idea for partially lazy imports looks like a good first optimization to me. Selective imports always override symbols of the same name in other imported modules, right?

-- 
Marco

On 12/20/2013 09:43 PM, Martin Nowak wrote:
>
> Couldn't static imports be made lazy without breaking any code?
> The above example would read.
>
> static import std.range.
>
> void foo(R)(R range) if (std.range.isForwardRange!R)
> {
> }

Furthermore selective import can always be made lazily without changing code.

import std.algorithm : min;

Only if `min` or `std.algorithm` are used the compiler needs to open std.algorithm.

On 1/5/14 5:22 PM, Martin Nowak wrote:
> On 12/20/2013 09:43 PM, Martin Nowak wrote:
>>
>> Couldn't static imports be made lazy without breaking any code?
>> The above example would read.
>>
>> static import std.range.
>>
>> void foo(R)(R range) if (std.range.isForwardRange!R)
>> {
>> }
>
> Furthermore selective import can always be made lazily without changing
> code.
>
> import std.algorithm : min;
>
> Only if `min` or `std.algorithm` are used the compiler needs to open
> std.algorithm.

I thought more about this and I think that's wrong. Making all imports lazy would be a net large win.

The missing link is transitivity: if one imports only min from std.algorithm, std.algorithm itself indeed needs to be opened and parsed, but ONLY transitive imports of std.algorithm that min itself needs would be opened.

We can do lazy importing with no change to the language semantics/


Andrei

On 1/5/14 5:22 PM, Martin Nowak wrote:
> On 12/20/2013 09:43 PM, Martin Nowak wrote:
>>
>> Couldn't static imports be made lazy without breaking any code?
>> The above example would read.
>>
>> static import std.range.
>>
>> void foo(R)(R range) if (std.range.isForwardRange!R)
>> {
>> }
>
> Furthermore selective import can always be made lazily without changing
> code.
>
> import std.algorithm : min;
>
> Only if `min` or `std.algorithm` are used the compiler needs to open
> std.algorithm.

I thought more about this and I think that's wrong. Making all imports lazy would be a net large win.

The missing link is transitivity: if one imports only min from std.algorithm, std.algorithm itself indeed needs to be opened and parsed, but ONLY transitive imports of std.algorithm that min itself needs would be opened.

We can do lazy importing with no change to the language semantics.


Andrei

2014/1/6 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>

> On 1/5/14 5:22 PM, Martin Nowak wrote:
>
>> On 12/20/2013 09:43 PM, Martin Nowak wrote:
>>
>>>
>>> Couldn't static imports be made lazy without breaking any code? The above example would read.
>>>
>>> static import std.range.
>>>
>>> void foo(R)(R range) if (std.range.isForwardRange!R)
>>> {
>>> }
>>>
>>
>> Furthermore selective import can always be made lazily without changing code.
>>
>> import std.algorithm : min;
>>
>> Only if `min` or `std.algorithm` are used the compiler needs to open std.algorithm.
>>
>
> I thought more about this and I think that's wrong. Making all imports lazy would be a net large win.
>

Honestly, "lazy import" (== defer loading module file and running semantic analysis for symbol search) would improve compilation speed for selective imports and static imports, but it would have no merit for basic imports.

So precisely, "all imports lazy would be a net large win." is not correct.

Kenji Hara