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 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.

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. 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