Module system of D2: to be fixed still

[Georg Wrede]

bearophile wrote:
> Leandro Lucarella:
>> grauzone:
>>> - the current import semantics should be redone such that "import
>>>   a.b.c.d;" works like "import d = a.b.c.d;", and add a new syntax like
>>>   "import a.b.c.d.*;" to get the current behavior
>> Shouldn't be static import a.b.c.d;? It's a little odd to get imported
>> just the last part. I'm not convinced though.
> 
> davidl:
>> Yes, the package does not offer us enough functionalities. However,
>> only saying "I have discussed/talked/stated/complained something XXX
>> times" does nothing good to the current state. Contrarily, I prefer
>> one list the reasons of why current one is broken and corresponding
>> sophisticated solutions.
> 
> I can answer both, adding a small change from what I have said last time :-)
> 
> import foo;
> Imports in the current namespace the "foo" module name.
> 
> import foo: *;
> Imports in the current namespace all the names inside foo, but not the "foo" module name itself.
> 
> import foo: bar, baz;
> Imports in the current namespace the "bar" and "baz" names, but not the "foo" module name.
> bar and baz can be anything, packages too.

It's a shame that I never took a combinatorics course. This whole issue 
looks like a homework assignment from the second semester:

"(0) Enumerate the set of use cases for importing source code modules. 
(1) Outline the minimum amount of directed graphs that covers all these 
use cases. (2) Either prove that circular graphs are unavoidable, or 
show how they can be avoided with a standard transform." etc.

At any rate, we should totally avoid discussing syntax *until* we have 
come up with the requirements that are needed. There's no use in 
cluttering the discussion with syntax while we aren't clear on exactly 
what is needed (and what is not needed).

Oh, and for clarity, we probably should define Circular as a mutual or 
an a->b->c->a dependency. The case a->b->d + a->c->d is, IMHO not 
Circular. It should have some other name, to avoid confusion.

As for Friend modules, these might arise when a library includes (for 
the sake of practicality) sub-modules. Can the library programmer be 
required to refactor the Friend needs to a new module that the other two 
both import?

A library with a main and sub modules, where the sub modules may be 
individually imported (as in std.c.whatever), seems to impy that 
importing the sub module does not necessitate making the main module 
visible. It seems to merely be a path component in finding the sub 
module. Probably this should be the norm.


(Just scratching the top of the iceberg here.)