On 12/19/2016 01:47 AM, Joakim wrote:
Why do you care _so_ much about the module dependency graph? To make
this question concrete, let's look at an example, the std.array module
you keep mentioning.
This is what it looked like before Ilya scoped as
many imports as he could:
https://github.com/dlang/phobos/commit/3fcf723aa498b96de1653 61b5abb9d3450fdc069#diff-54cf8 402b22024ae667d4048a5126f0e
That was a mess, similar to opaque C/C++ code, 13 modules imported at
module-scope were whittled down to 4. You just made those more specific
in a commit related to this DIP, by listing the actual symbols
selectively imported from those four modules:
https://github.com/dlang/phobos/commit/e064d5664f92c4b2f0866 c08f6d0290ba66825ed#diff-54cf8 402b22024ae667d4048a5126f0e
If I'm looking at the template constraints for any particular function
and see a couple symbols I don't recognize, I don't think it's a big
deal to find the symbols in that list at the top.
It actually is. Some symbols in e.g. std.range are used in constraints, some others used in definitions; some in a UFCS manner. Some code runs during compilation, with errors gagged (as in __traits(compiles)) or not gagged. I don't know of an easy manual method to figure out who's who (which makes Vladimir's idea of tooling it with brute force awesome and scary at the same time).
At any way, I don't see how I can use this tidbit to improve the DIP. Anything I could add to it to make it more compelling?
In other words, D already allows you to scope most imports. I don't
consider the dozen or two remaining symbols from templaint constraints
and function arguments to provide much overhead. Rather, I consider the
weight of this additional syntax, ie the cognitive overhead from having
to remember and parse more syntax in my head, to be worse than the
remaining dependency reasoning problem you're trying to solve: the cost
outweights the benefit. Perhaps that's subjective and others may disagree.
It is subjective and difficult to convert into action. Online review among folks who know next to nothing about each other does have its challenges. What happens here is I post a proposal for a problem that I believe is important for large D projects. And I get back "eh, that's not as important to me." At a traditional work place we'd know a lot about one another's strengths, specialization areas, and design sensibilities. Here, all I can do is look at your past PRs (that's why I emailed you asking for your github handle; I figure it's @joakim-noah). This makes it difficult to act on "I don't buy it" feedback.
Now, there's also the question of purely technical benefits, like
compilation speed or executable bloat. I looked at the latter a little
last summer, after Ilya had cleaned up a lot of the standard library:
http://forum.dlang.org/thread/gmjqfjoemwtvgqrtdsdr@forum.dla ng.org
I found that commenting out a single scoped, selective import of
"std.string: format" in std.utf led to a 5% decrease in executable size
for "hello world." This is a problem with how dmd compiles or appends
these module dependencies and would presumably still be there after this
DIP, as you would not remove the dependency.
That might be a related but distinct issue. Can you reproduce that experiment?
I think scoped, selective imports have been great at hacking away at the
module dependency graph, as you lay out. It is not clear what technical
costs you see from the remaining few dependencies and if this DIP is the
best way to remove them. I think you should explain why you want to
untangle the remaining dependency graph, and consider if this DIP is
really doing that much.
I've made a few more passes through the DIP, but throughout I assume a couple of things without stressing them too much - dependencies are important, and associating dependencies with declarations makes the dependency graph as fine and as precise it could get. I don't see a reasonable way to make it better or clearer.
Should I add an introductory section on why dependencies are important?
Andrei