Proposal: module namespaces.

[Malcolm Wallace]

Simon Marlow wrote:

> The compiler finds the file because you tell it what the filename is.
> That's the way it works now, and if I understand correctly Malcolm isn't
> suggesting we change that (and I agree).

Yes, that's what I had in mind.  My guiding design principle is that 
I want absolutely minimal changes to the current way of doing things,
while still managing to gain new expressiveness in the module namespace.

> There are really two issues here:
> 
>   * how do you find a module to compile in the first place (not an
>     issue for interpreters, only for batch compilers).  Just run
>     the compiler giving it the filename.

Exactly.  When the dot-extended module name is explicitly given,
in full, in the source file's "module" header, then it doesn't
matter where the compiler is invoked from.

    cd .; ghc -c A/B/C/D.hs
    cd A;   ghc -c B/C/D.hs
    cd A/B;   ghc -c C/D.hs
    CD A/B/C;   ghc -c D.hs

are all equivalent.  No special flags are required to tell the
compiler that the "root" of this tree is at the parent of A.  The
source file contains everything the compiler needs to know.

>   * when you import a module, how does the compiler find the interface
>     (or source, in the case of an interpreter) for the target.
> 
>     My feeling is that this happens with a small extension to the
>     current scheme: at the moment, the compilers all have a list of
>     search paths in which to find interfaces/sources.  The change
>     is that to find a module A.B.C you search in D/A/B/ (for each D
>     in the search path) rather than just D.

I can confirm that Simon's interpretation was exactly what I
intended, once again.

> GHC's package mechanism will actually work pretty much unchanged with
> this scheme, I believe.

Good.  I don't know much about the package mechanism.  Is there a
specification document available on the web?

Regards,
    Malcolm