Libraries and hierarchies

Simon Marlow simonmar@microsoft.com
Fri, 8 Aug 2003 09:33:23 +0100


> Yes.  I would have thought that library authors would want to avoid
> this.  I guess you don't mind: the library user just grafts one of the
> libraries in somewhere else.  So the mapping supplied with=20
> the package is
> presumably just a default that can be overridden.  And to read someone
> else's source code I also need their personalized mappings for the
> various packages they're using.
>=20
> So you have extended the syntax of the language: you need a syntax for
> these mappings, and the static semantics operates on ordinary source
> plus this mapping language.

Thinking about it, I'm not sure that the language definition needs to be
extended at all, to allow the proposed scheme. =20

The language definition (with hierarchical modules, of course) continues
to specify the meaning of a collection of modules, each with an absolute
module name.  What we are proposing is two mechanisms that the
compilation system can provide so that the user has more flexibility in
constructing a set of modules with absolute names.

  1. A method by which a module can change its module name after
     being compiled.

  2. A method by which a module can be exposed as several absolute
     module names to future compilations.

I think these could be expressed as source-to-source transformations,
leaving the Haskell 98 + hierarchical modules spec as it is.

What about the mappings between packages and sites?  Don't we need to
specify a syntax for these, and include it in the language spec?  I
don't think so.  This is all just a facility provided by the compilation
system for populating the module namespace with modules - we don't need
to add it to the language, in the same way that we don't need to include
search paths and filenames in the language.

This is something of a technicality I suppose, but it's nice to know
that the language spec can remain unchanged.  It's also useful to
cleanly separate the meaning of a program as a set of modules, from the
means by which we arrive at that set of modules.

Cheers,
	Simon