Proposal: module namespaces.

[Marcin 'Qrczak' Kowalczyk]

Wed, 28 Feb 2001 11:44:58 +0100, Christian Brolin <Christian.Brolin@carmen.se> pisze:

> > It does not. File A/B/C/D.hs can be module A.B.C.D, or module B.C.D which
> > happened to be placed in a directory A, or C.D etc. It's ambiguous.
> 
> Only if you give the compiler include pathes to both ~ and ~/A, where ~
> is the directory containing your A.

When I am in the directory and compile D.hs, I get different result
than when I'm one level up and compile C/D.hs? It's fragile.

> I just want to left out the redundant information, and . and .. are what
> remain.
> import .D2 -- import [A.B.C].D2
> import ..E -- import [A.B.C].[D].E

Skipping D alone is not a big deal, and it's known because it's the
current module, so the second form is not needed - you could say .D.E
as well.

It's still confusing: in path names, you write the initial '/'
for an absolute name and omit it for a relative name, but here
it's the opposite. I would drop it.

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).

A prefix to add to names of compiled modules will have to be
specifiable at the compiler commandline, otherwise projects would be
forced to put all their files in deep subdirectories only to generate
right module paths.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK