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