Proposal: module namespaces.

[Christian Brolin]

Marcin 'Qrczak' Kowalczyk wrote:
> 
> 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.

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.

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

Or A.B.C.D.E, so the first is not needed either. The idea is to avoid
redundant information, not to save some typing. I can go with:
import parent.D2
import parent.this.E

where 'parent' and 'this' are two new reserwed words. I want relative
addresses to be able to easily move packages of modules. 

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

What? The concept of relative addresses or just my home made dot-syntax? 

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

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

Yes, in the case of a file system, you have to specify a set of
directories for the compiler to search for the sources. The compiler
should look for the module A.B.C.D and not the module D.

I would like to compile the program above with:
hcc -i~brolin/haskell/test A.B.C.D

The compiler understands the import clauses and locates the imported
modules and recursively compiles the ones that need to be compiled.

The above command is not the same as:
hcc -i~brolin/haskell/test/A/B/C D

Since this compiles the module D and not the module A.B.C.D. (The last
dot is a period and is not part of the module identification:)

The module A.B.C.D can be mapped to the file system, e.g. Unix:
~brolin/haskell/test/A/B/C/D.hs
or maybe:
~brolin/haskell/test/A.B.C.D.hs
or maybe a compiled package:
~brolin/haskell/packages/ABCD.har

--
Christian Brolin