Haskell Libraries Project Status report, September 2001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Back in February of this year, Malcolm Wallace proposed an extension
to Haskell to support a hierarchical module namespace, and gave some
suggestions as to how Haskell might use the extended namespace.  The
original message is here:

   http://www.mail-archive.com/haskell@haskell.org/msg08187.html

At the same time, a mailing list for discussion of the changes was set
up, libraries@haskell.org.  The archives are here:

   http://www.haskell.org/pipermail/libraries/

This report details the current status of the proposal, and outlines
what we've been up to on the mailing list.  There is also an evolving
document describing the current proposal; an HTML version can be found
here:

   http://www.haskell.org/~simonmar/libraries/libraries.html

THE LANGUAGE EXTENSION.  A minimal extension to Haskell 98 has been
agreed, namely to allow '.' as a valid character in a module name.
The extension is supported by released versions of GHC and nhc98, and
will be supported a by future release of Hugs.  The mapping from
module names to file names, although not part of the Haskell 98
standard, will also be similar between the implementations.

Further extensions have been suggested, such as those to allow
importing or renaming of multiple modules simultaneously, but none has
been settled on.  We're waiting until we have more experience with
using the hierarchical scheme before deciding what further extensions,
if any, are necessary.

THE HIERARCHY.  We settled on a rough outline of what the hierarchy
should look like to a Haskell programmer.  The guiding principle we
agreed on was that the hierarchy should reflect functionality, so
libraries with similar functionality should be grouped together.  One
consequence of this decision is that whether a library is "standard"
or not should not be reflected in its name or its position in the
hierarchy.

THE LIBRARIES.  We came to the conclusion that there ought to be a
single set of "core" libraries used by all the implementations, with
sources kept in a single place.  Several issues surrounding the core
libraries, such as licensing, versioning, portability & stability have
been discussed; the current working proposals are detailed in the
working document (URL above).

Work has begun on constructing the core libraries.  The current
sources can be perused in the CVS repository, here:

   http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/

the current status is that most of GHC's old hslibs libraries have
been migrated into the new framework, with the exception of posix,
edison, HaXml, Parsec and a few others.  GHC runs with the new
libraries, but the development version of GHC hasn't fully switched
over to the new scheme yet - this is expected to happen before the
next major release of GHC.

TODO.  Much remains to be done, and there's ample scope for
contribution: providing implementations of libraries, designing
interfaces to libraries, pointing out problems and inconsistencies in
existing libraries, testing implementations, porting the core
libraries to other compilers/platforms, and so on.