Proposal: module namespaces.

[Simon Marlow]

[ leaving out haskell@haskell.org from the recipient list ]

> Malcolm Wallace wrote:
> > 
> > Christian writes:
> > > What about the module declaration? Should it be:
> > >   module Text.Xml.Parser where ...
> > > or just
> > >   module Parser where ...  -- located in Text/Xml/Parser.hs?
> > 
> > The former.  The reason is that a compiler needs to 
> generate a unique
> > linker symbol for each defined function.  If the full module name is
> > not encoded in the source file, you will need to add a commandline
> > option to the compiler, which is the wrong way to go in my opinion.
> 
> What?? The compiler knows the full name of the module without 
> the module
> clause. If it didn't do that, it can't find the modules to 
> compile! Does
> the compiler opens every file on the Internet to check 
> whether it is the
> file to compile? How does the compiler find the file to compile in the
> first place? What should the command line option you mentioned do?

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

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.

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

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

Cheers,
	Simon