Reducing the inter-dependencies (in Phobos and at large)

[Dmitry Olshansky]

26-Apr-2013 07:23, Jonathan M Davis пишет:
> On Wednesday, April 24, 2013 16:03:47 Dmitry Olshansky wrote:
>> What we need is to re-arrange the module hierarchy (and we need that
>> anyway) so that we split off the "concept" part of modules to a separate
>> package.
>
>> Thoughts? Other ideas?
>
> I'm a bit divided on the idea. On the one hand, it allows us to reduce
> interdependencies. On the other hand, it's definitely complicating the module
> hierarchy. This whole idea is a bit like the .h/.cpp or .di/.d separation.

In general what I propose is a special case of reducing artificial 
dependencies due to coarse-grained modularization.

Now C had a crude mechanism for hiding details and achieving 
modularization, we have proper modules (and OT: awful visibility rules).

> On
> the whole, I prefer the model of shoving it all in one file, but given that
> Phobos is the standard library (of a _systems_ language no less), the added
> complication may very well be worth the benefits in dependency reduction.

Yup.

> Still, given that we're talking about templates here, most of it shouldn't end
> up in the generated executable or library if it's not used, and we've already
> been moving away from static constructors in Phobos, and global/module level
> variables should already be quite rare.

Still not the case, hence the proposal. In general there are globals 
(and TLS) and they are useful in their own right and there is nothing 
better when you need that functionality.

> And once Phobos is a shared library,
> the few global/module level variables we have should cost even less.

False - the cost is _always_ there as dynamic linker still has to pull 
that stuff off disk and run ctors/dtors.
The only gain is that running multiple D binaries linked against the 
same phobos will share its code in memory. That and the "binaries look 
small" argument :)

If D was the default systems language on some platform (like C does) it 
would also mean having run-time always there (thus you wouldn't have to 
ship it).

> So, I'm
> not sure that the extra complication is really worth it. If the compiler and
> linker are doing their job, the only real difference should be in how much the
> various modules in Phobos need to be parsed, which is very fast with dmd, and
> most programs of any size are going to pull in all of the dependencies anyway.

Have you read the description? I gave the exact cases where regardless 
of templates or no templates you do pull in the module. This is a 
problem that defeat the whole goodness of generating only the code you 
use (via templates). In fact I'll post about more specific problem 
separately (need to gather the solid data).

And I would question the "most programs of any size are going to pull in 
all of the dependencies anyway". All programs are different. And I'm 
more concerned with Phobos itself and libraries.

The proverbial sufficiently smart compiler that trims down things to 
establish true per symbol dependency may never come (unless we change 
compilation model at the same time)

> I'm inclined to avoid doing this if we don't really need to, but if there's a
> solid benefit to it, then it may be that we really should do something like
> this.

Would have to show it then. One such benefit may as well be being able 
to avoid forward reference hell with the current compiler. Fake circular 
dependencies is the 2nd one.

Thinking more of it - the idea would have been neat and elegant with a 
variation on DIP 15. Then std.xyz.trait would be the trait part of a 
package.

http://wiki.dlang.org/DIP15

>
> On a side note, given that we sometimes call eponymous templates like
> isForwardRange traits, calling the sub-module trait or traits rather than
> concepts might be better (probably std.trait given that std.traits is already
> taken, though that would probably then become std.trait.traits given that it's
> entirely made up of traits).

Yeah, I thought as much. Concept has no established usage in D culture, 
so trait it is.



-- 
Dmitry Olshansky