Proposal: module namespaces.

[Christian Brolin]

Marcin 'Qrczak' Kowalczyk wrote:
> 
> Wed, 28 Feb 2001 17:31:13 +0100, Christian Brolin <Christian.Brolin@carmen.se> 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