Re: Proposal: module namespaces.

Marcin 'Qrczak' Kowalczyk wrote:

Wed, 28 Feb 2001 17:31:13 +0100, Christian Brolin pisze:

...

This dilemma comes from the fact that you don't tell the compiler what module to compile, but just give it some Haskell code. You should always compile the module with: compile A.B.C.D, i.e. tell the compiler which module you want to compile, and the compiler will find the source code.

It must work well with Makefiles. I can imagine that it's doable in this case, but generally it should work to specify the filename too.

If it isn't double, it is not possible to automatically find the files of imported modules!

...

...

Instead I would let the current directory play as an implicit module root. I.e. you can refer to D2 as D2, and in this case you cannot refer to the global module D2 if it exists (but you can refer to D2.Other if D2 is a global directory and there is no local directory named D2).

I think this is very confusing! And restrictive.

It may be confusing (but not more than having your own function called sortBy).

sortBy?

It's not restrictive. When you want to use a module, don't provide a module of the same name - *that* would be confusing when used (if allowed).

You can't import a child module without mention the name of the importing module.

It has an advantage that it's simpler. The compiler has a set of roots and there is just one form of module paths.

I think it is better to explicitly distinguish between absolute and relative addresses of imported modules. It would be easier for a reader (e.g. a compiler) to find the modules. Absolutely imported modules are found by looking in the set of roots, while the others are found relative to the position of the current module. -- Christian Brolin