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

On Saturday, April 27, 2013 00:26:05 Dmitry Olshansky wrote:
> 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

We really do need a variant of DIP 15 or 16. I actually started looking into it briefly at one point, but that's way outside my area of expertise, and I'm annoyingly busy these days.

- Jonathan M Davis

27-Apr-2013 00:26, Dmitry Olshansky пишет:
> 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).

Here is the example of the primary catch. Let's say you have 3 modules a, b and the main app module m. b depends on a's constraint.

module b;

extern(C) void printf(const(char)* fmt, ...);

template canCheckIn(T)
{
    enum canCheckIn = is(T : int);
}

static this()
{
    printf("START b\n");
}

static ~this()
{
    printf("END b\n");
}

module a;

import b;

extern(C) void printf(const(char)* fmt, ...);

void foo(T)(T value)
    if(canCheckIn!T)
{
    printf("FOO\n");
}

void bar()
{
    printf("BAR\n!");
}

module m;

import a;

void main()
{
    bar();
}


main will happily print:
START b
BAR
END b

Even though foo is not even instantiated(!) and it's the only thing in which a depends on b (and m doesn't ever touch it).

Now multiply this be the kind of cross-import happy graph we have in Phobos and indeed most programs are going to pull in the whole ball of mud.


-- 
Dmitry Olshansky