DIP16: Transparently substitute module with package

Michel Fortin michel.fortin at michelf.com
Fri Mar 30 14:45:36 PDT 2012


On 2012-03-30 14:46:19 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Destroy!

Since you're asking…

One thing the current system avoids is unresolvable symbols. If two 
symbol name clashes, you just qualify them fully and it'll always be 
unambiguous. For instance:

	.std.algorithm.sort(…)

Now, if std.algorithm becomes both a module and a package, you could 
have both a sort function and a sort submodule with no way to 
distinguish between the two, even when fully qualified. I think this is 
why D does not allow modules to have the same name as packages.

I understand that you try to work around this problem by inventing a 
.std.algorithm.package scope. Then you make it's content imported 
automatically inside the .std.algorithm scope for backward 
compatibility (and convenience). The problem is that if 
.std.algorithm.package contains a sort function and there is also a 
module called std.algorithm.sort, the fully-qualified name of that 
'sort' module will become ambiguous. Moreover, whether the 
fully-qualified name .std.algorithm.sort is ambiguous or not depends on 
what modules were imported, which is not a very desirable behaviour.

So to make sure there is no unresolvable fully-qualified names, when 
importing std.algorithm.sort the compiler should make sure that no 
symbol called 'sort' already exist in the .std.algorithm scope (which 
includes the symbols in .std.algorithm.package and all other packages 
inside std.algorithm). This is clearly untenable.

 - - -

I recognize the need. If I may, I'll propose something simpler:

1. allow both std/algorithm.d and std/algorithm/sort.d to exist
2. importing std.algorithm.sort will also implicitly import 
std.algorithm (if it exists) and std (if it exists)
3. if any symbol of std.algorithm clash with the std.algorithm.sort 
module name, you get an error when importing std.algorithm.sort.

Effectively, importing std.algorithm.sort becomes synonymous to 
importing std, std.algorithm, and std.algorithm.sort. This is what's 
needed to detect clashes in fully-qualified names.

The only issue now (beside a few more imports) is that if std.algorithm 
imports any of its submodule it becomes a circular import. That's 
usually fine in D, but not when you have module constructors.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list