Package "mounting" proposal

[Simon Peyton-Jones]

| In particular, I propose to drop the assumption that Haskell modules
are
| closed entities but rather always consider them to be seen in the
context
| of a particular _package_. The package is now made responsible for
| assembling an appropriate (hierarchical) module namespace to which
imports
| in the packaged modules are taken to refer. To this end, the current
| 'depends:' entry in a package description would be replaced by a more
| general "mounting" construct, i.e. "mount package foo at Foo.Bar in
the
| module hierarchy". Optionally, as in [2], only a subtree of "foo"
could be
| selected, or only a specific version of "foo".

In fact what Sven describes is very close indeed to what Simon and I
propose, which is great.  Just as the imports of a module establish the
name-space for entities mentioned inside the module, so the Cabal file
(plus the installation setup) establishes the name-space for modules
specified in import statements (both unqualified 'import M' and
package-qualified 'import "gtk" M).  So the analogy is that
	the package dependencies of the Cabal file
		corresponds to
	the import statements of a module

We propose to use this analogy consistently:

** In a module you can mention an entity both unqualified 'f' (if that
is ambiguous) and qualified 'M.f' (to disambiguate); so in an import you
should be able to mention the module both unqualified 'import M' (if
that is umambiguous) and qualified 'import "gtk" M" (to disambiguate)

** In a module you can import another module 'qualified', so that its
entities MUST be referred to qualified (import qualified
M(f);....M.f...).  So, in the Cabal file, you should be able to say that
the exposed modules of a package are only available by qualified import
('import "gtk" M).

** In an import statement you can give an alias ('import M as Q").  So,
in a Cabal file, when giving the dependency on a package, you should be
able to specify an alias (needs new syntax).  For a start, when
depending on "gtk-4.2.3" you probably want to give it an alias "gtk", so
that the source code of the package mentions only "gtk" not the exact
version".

** In an export statement of a module you can say what is exported.
Cabal already has that, via the list of 'exposed' modules.

** In an 'import' statement you can bring into scope a subset of the
entities exported by a module.  Such a selective import would make
perfect sense at the package level too, but it's not so clear to us that
it's worth the bother.


How does this differ from what you propose?  Only in the following way:
instead of allowing a qualified import (i.e. one specifying a particular
package, or package alias), you build a single module name space, and
only allow unqualified imports. Instead of 
	import "gtk" M
you would establish "GTK." as the prefix for package "gtk", and then say
	import GTK.M.
This isn't a very big difference (which is good).  Personally, I like it
less, because it conflates *provenance* (where the module comes from)
with *purpose* (what it's for) in the single name.  Furthermore, the
qualified/unqualified analogy lets us import modules unqualified when
that's unambiguous, and qualified when it matters.  


Incidentally, everywhere I say "Cabal" I also mean "GHC's command line"
(or Hugs or nhc etc).  All Cabal does is invoke the compiler with
suitable arguments.

Simon