On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2012-04-04 14:08:34 +0000, "Steven Schveighoffer"
<schvei...@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
