What follows is a proposal from Simon P.J. and myself, for solving some
of the problems that have arisen with hierarchical modules in Haskell.
We think this is quite a nice solution: it decentralises the allocation
of names, allows versioning of libraries and referencing libraries by
GUID, allows relative module names, and allows moving modules within the
hierarchy without changing the source code, all without adding any extra
syntax :-)
Please tell us what you think. This will only get adopted if everyone
agrees, because it needs all the Haskell implementations on board in
order to work.
THE PROBLEM
-----------
Problem 1: Allocating names in the hierarchy
At the moment, we have a scheme of central registration (albeit
informally on this list), along with a way for users to name libraries
based on their email address (eg. User.Com.Microsoft.Simonmar.Foo).
This is unsatisfactory, because (a) having a central registry for
names is too cathedralish, and (b) it's inconvenient to use the
email-address form because it gives rise to overly long module names.
Problem 2: Moving a module tree around
Suppose you have a tree of modules Control.Monad, Control.Monad.X,
Control.Monad.Y etc, and you want to move them from Control to some
other place Foo.Baz in the hierarchy, to give Foo.Baz.Monad,
Foo.Baz.Monad.X, etc. At the moment you have to visit every module
and change its module header to give the correct absolute path name.
Problem 3: Long module names in imports
It's plain tiresome to have to write
import User.Simon.Text.PrettyPrint.HughesPJ
Long path names, repeated all over the source tree, are painful.
They are particularly painful when you want to refer to another
module in the same library -- then, if you decide to put the library
somewhere else, you have to change all its internal imports.
A POSSIBLE SOLUTION
~~~~~~~~~~~~~~~~~~~
The key idea is this: there is no longer a single global hierarchy of
modules, but every site and every user has the means to populate their
own module hierarchy as they see fit, with off-the-shelf and local
libraries.
This means that when you install a package (a sub-hierarchy of modules),
you get to choose where in the global hierarchy on your system it is
rooted. There would probably be a default, which you would most often
go along with unless it clashes with another library on your system, in
which case you might choose to site it somewhere else. You can even
choose to site it in several places in the tree.
If you want several versions of a library installed on your system, you
can do that too, provided you site them at different places in the
hierarchy. If you install a new version of a library, just re-site the
old one to a version-specific place, and install the new one.
eg. I install the GTK+HS library on my system. By default, it sites
itself under
Graphics.UI.Gtk.*
Graphics.UI.Gtk.V0-15.*
and possibly additionally sites itself under a GUID-based root, or one
based on an API hash:
GUID_XXXXXXXX_XXXX_XXXX_XXXX_XXXXXXXXXXXX.*
When I install a new version of GTK+HS, say version 0.16, I can replace
the existing Graphics.UI.Gtk with the new version, and I now have:
Graphics.UI.Gtk.* -- now refers to version 0.16
Graphics.UI.Gtk.V0-15.*
Graphics.UI.Gtk.V0-16.*
and two distinct GUID sites.
You could even use this mechanism, in a per-user configuration file say,
to site the GTK+HS library directly in Gtk.*, if you're too lazy to type
Graphics.UI all the time. This wouldn't be recommended though: any
source code you write won't compile on someone else's system that
doesn't have the same convention.
PACKAGES and DISTRIBUTION
~~~~~~~~~~~~~~~~~~~~~~~~~
A "package" is the unit of distribution. A package includes a
sub-hierarchy of Haskell modules, as well as perhaps other stuff (such
as C header files etc). When installing a package one specifies one or
more "sites" at which the modules are to be grafted into the module
hierarchy. A site is just the module prefix to be used for modules in
that package. The sub-hierarcy within a package is not changed by
re-siting. A package comes with a list of "default sites", where it
will be installed by default.
It is an install-time error to graft in a package at a site that means
that a single module name is defined twice.
The actual representation of a package in distributable form may vary
between implementations. For example, Hugs may need only source files,
while GHC may distribute interface files and binaries. All that matters
is that for any particular implementation (Hugs, say) there's a
specified way to take a package and install it at one or more sites in
that Hugs-compiler's module hierarchy.
For example, GHC's package configuration for an installed package
currently looks something like this:
{
name = "mylib",
import_dirs = ["/usr/local/lib/mylib/imports"],
...
}
and we suggest adding an extra field, sites:
{
name = "mylib",
import_dirs = ["/usr/local/lib/mylib/imports"],
sites = [ "Foo.Bar.MyLib", "Foo.Bar.MyLib.V2.3", "GUID_XXXX" ]
...
}
SOURCE CODE
~~~~~~~~~~~
What about module names in the source code, and how are modules
compiled? Suppose I am compiling a package whose default site is
Foo.Bar, and containing modules Foo.Bar.A.B, and Foo.Bar.A.C (assuming
it is installed at the default site). I put the source code in A/B.hs
and A/C.hs, and the code would look like this:
module A.B where
import A.C
The implementation must obey the following rule:
When compiling a module belonging to a package, that package
is temporarily grafted into the root of the module hierarchy.
This means that 'import A.C' will find the module A.C from the package
being compiled. If there is already a global module A.C, the package
module "wins"; so the global module A.C is inaccessible. (There could
be some extra mechanism to get around this, if it seems important.)
Modules in other packages can be imported only by uttering their full
path names in the global hierarchy (of the compiler that is compiling
the package).
After installing the library, the tree of modules it contains will be
grafted into the global hierarchy at possibly many places, and the
modules can then only be imported by uttering their full path names in
the global hierarchy.
Alternative design: modules in the current package could be specified
explicitly, perhaps by prefixing them with '.'. This would avoid the
possibility of overlap between the current package and the global
hierarchy, at the expense of having to add lots of extra '.'s.
IMPLEMENTATION
~~~~~~~~~~~~~~
How do we implement this? For Hugs, it should be relatively
straightforward; two implementations spring to mind. Either
(a) transform the source files as they are installed, to
replace package-relative module names with absolute names.
Multiply-sited packages are implemented by copying and
transforming the source code into several places.
(b) have Hugs do the module fixup at load-time, and change the
search strategy to take into account package-relative imports.
Multiply-sites packages can be done with symbolic links, or
straight copying of source files.
For GHC and other systems with compiled libraries, it's a bit trickier.
We need to make sure that each symbol in the compiled library cannot
clash with any symbol in any other library. One way to do this is to
include the package name in each symbol, and require that package names
are unique (perhaps include a GUID in a package name).
