DIP16: Transparently substitute module with package

Steven Schveighoffer schveiguy at yahoo.com
Wed Apr 4 10:53:24 PDT 2012


On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2012-04-04 14:08:34 +0000, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>>  The FQN cannot be ambiguous.
>
> Sure it can if I follow DIP16, because module names can become ambiguous.
>
> Let's try this with an example. First, let's define a pretty standard  
> module:
>
> std/algorithm/sort.d:
>
> 	module std.algorithm.sort;
>
> 	void sort(T)(T[] array);
>
> Here the fully-qualified name of the sort function is  
> .std.algorithm.sort.sort. But according to DIP16's lookup rules, the  
> sort function is also available (if not ambiguous) at:
>
> 	std.sort
> 	std.algorithm.sort
>
> Question 1: since there is already a module at .std.algorithm.sort,  
> doesn't the module name become ambiguous with the sort function it  
> itself contains?

OK, but when is it ever valid to refer to a module when the semantic  
expectations are for something other than a module?  I can only think of  
two places where module names are used, inside an import statement and  
inside a module statement (three if you count the prefix of a FQN).  Maybe  
I'm missing some case...

> Let's assume the module's name take priority and does not conflict so we  
> can continue. Now we create the package.d file:
>
> std/algorithm/package.d:
>
> 	import std.algorithm.sort;
>
> And now I write this somewhere in my code:
>
> 	std.algorithm.sort
>
> Question 2: does std.algorithm.sort refer to the std.algorithm.sort  
> *module* or to std.algorithm.package.sort *function* publicly imported  
> from the std.algorithm.sort module?

The function.  A symbol that is not specified as the module name in import  
statement or in a module statement is always *not* a module.  I think our  
one saving grace here is that when you want to import a specific symbol  
 from a module, this is not the syntax:

import std.stdio.writefln;

So there is never any ambiguity as to whether you mean a module identifier  
or other symbol.

> You might think I'm trying to split hair in four to find flaws, that no  
> one is going to do things that dumb, but I unfortunately think the  
> problematic pattern is already quite common. How many times have we seen  
> modules containing a class, variable, or function having the same name  
> as the module's name?

Tango anyone? :)  But yes, I think the issue really becomes, we need to  
look at context when deciding the semantic meaning of a symbol.  I don't  
think this violates the context-free grammar, because wouldn't this only  
come into play at the semantic level?  Not a compiler writer/hacker, so I  
don't know.

> Say you wanted to create a package.d file directly for the whole package  
> std, what should be done for those?

No, let's not do that.  Ever. :)

-Steve


More information about the Digitalmars-d mailing list