DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrei Alexandrescu via Digitalmars-d]

On 12/24/2016 12:52 PM, Chris Wright wrote:
> On Sat, 24 Dec 2016 04:34:03 -0500, Andrei Alexandrescu wrote:
>> Upon more investigation, I see a large discrepancy between the findings
>> of DIP1005 and yours.
>
> There's no discrepancy.
>
> In part, you are misinterpreting most of what I said.

Yah, I suspected so.

* Your post provided no description of the methodology used beyond 
"relatively simple regex" to come up with the magic number 26, so I 
tried to use interpretation.

* There is no answer to "where is cmp on that list for example?" to shed 
light on what 26 is about.

* I have no access to your method of measurement, the scripts you used, 
or really what the claims are.

So I really don't have a good understanding of what hypothesis you have 
and how you arrived to it. DIP1005 carefully describes methodology and 
publishes measurements and results (which I'd be in your debt if you 
used - not those "published elsewhere"). Then it interprets the results.

> In part, you are assuming that imports on non-template declarations will
> be handled lazily, even though that is not part of this DIP, even though
> that is likewise possible with static and selective imports.

Imports in non-template declarations ARE handled lazily when those 
non-templates are imported. Consider:

module test;
void fun()
{
     import std.stdio;
     writeln("hello");
}

module test2;
import test;
void main() {} // let's not call fun

dmd -v test2.d

====
binary    dmd
version   v2.073.0-devel-bd0dec2
config    /home/andrei/bin/dmd.conf
parse     test2
importall test2
import    object	(/home/andrei/d/druntime/import/object.d)
import    test	(test.d)
semantic  test2
entry     main      	test2.d
semantic2 test2
semantic3 test2
code      test2
function  D main
cc test2.o -o test2 -m64 
-L/home/andrei/d/phobos/generated/linux/release/64 -Xlinker -Bstatic 
-lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl
====

Destroyed? This might be another misinterpretation of what you said though.

> In part, you are using lines of code as a proxy for compile time.

What do you suggest to use?

> In part, you dispute that this only affects template constraints, but:
> * An import used only in the body of a template can be made a local
> import today.

Correct. To the best of my knowledge, that fruit has been picked in Phobos.

> * An import used in the declaration of a templated type or function can
> be addressed by using explicit template syntax, offering a place to
> insert your imports.

Good thought. Would be a bit overkill though.

> * An import used anywhere else must still be processed, even assuming
> this DIP is implemented.

How do you mean that? On the face of it the sentence is true. Are you 
saying that you need to remove top-level imports to benefit from the 
DIP? That would indeed be the case.

> * If, in a future DIP, we make it so that `with(import)` is handled
> lazily, we can also make it so that static and selective imports are
> handled lazily.

That would be nice, but DIP1005 provides advantages beyond latency.

BTW it would be great if the discussion focused on (a) things that are 
true but the DIP doesn't mention (or misrepresents), or (b) things that 
are false that the DIP claims. I clearly concede that the DIP cannot 
convince someone with enough cognitive bias without an implementation 
and a few years of experience (and even then - aren't there folks out 
there who believe things like constraints, static if, or ranges are 
failures?).

>> The findings of DIP1005 are the following:
>>
>> * Importing a single std module also imports on average 10.5 other
>> modules.
>
> Seems reasonable. Between 2 and 3.5 direct dependencies, by my count, and
> you're counting transitive dependencies.

Shouldn't I? Shouldn't you?

> We're concerned with the effects of DIP1005, though, which only affects
> template constraints.
>
>> * Importing a single std module costs on average 64.6 ms.
>
> 55-ish for your hardware, you reported elsewhere. 47-ish for mine.

Let's stick with the numbers published in the DIP.

>> * (Not stated in the DIP) A majority of std templates would acquire
>> inline imports.
>
> Again, that wouldn't impact compile times because these aren't template
> constraints.

I don't understand this. YES it would impact compile times!

> You can make a separate DIP to make imports lazy. That can impact static,
> selective, and `with` imports equally well. But it's not part of what
> we're discussing today.
>
>> According to the DIP, one may estimate that the proposed feature would
>> reduce additional imports to 0 and the average time to import a single
>> module by a factor of 10 to under 10 ms.
>
> "The proposed feature" must be lazy semantic analysis, especially of
> imports. That isn't part of DIP1005.

The proposed feature is DIP1005. I really don't understand how your 
discourse goes.

> You won't get to zero additional imports. You might get to zero
> *extraneous* imports -- that is, only the set of imports required to
> create a custom *.di file containing only the parts of the module that
> your application uses.

You are wrong. With no top-level imports and all imports hoisted into 
inline imports, the fixed cost of importing one module will be that 
module alone. To focus the discussion, could we please focus on this one 
point?


Andrei