| First of all I want to thank Isaac Jones for his work on Cabal.
|
| There are a few issues I would like to raise.
Seconded -- Isaac you are doing a great job. As are lots of other
contributors.
One rather vexed question is the issue of whether a single program can
contain two modules with the same name. Currently that is absolutely
ruled out, and as a result packages are fundamentally non-modular: every
package must use a distinct space in the global namespace.
Simon Marlow and I have gradually become convinced that we have to fix
this, and the only sensible way to fix it is to relax the language
design so that
a module name must be unique within its package (only)
That means that module A.B.C could exist *both* in package P1 and in P2.
And both packages could be linked into the same program.
Some kind of 'grafting' or 'mounting' scheme would be needed to bring a
package into the package namespace. One might say
ghc -c Foo.hs -package gtk-2.3 Graphics.GTK
to mount the gtk-2.3 package at Graphics.GTK in the name space. Outside
the package one would need to import Graphics.GTK.M, but *within* the
package one just imports M. That way the entire package can be mounted
elsewhere in the namespace, if desired, without needing to change or
recompile the package at all.
The exact details of the mounting scheme, and whether it is done at
build time, at install time, or at compilation time, or all of the
above, are open to debate. We don't have a very fixed view.
However, the fundamental thing GHC needs to do is to include the package
name into the names of entities the package defines. That means that
when compiling a module M you must say what package it is part of:
ghc -C M.hs -package-name my-package-2.3
Then M.o will contain symbols like "my-package-2.3.M.f" etc. In effect,
the "original name" of a function f in module M of package P is