Libraries and hierarchies
Ross Paterson
ross@soi.city.ac.uk
Fri, 8 Aug 2003 10:11:02 +0100
On Fri, Aug 08, 2003 at 09:33:23AM +0100, Simon Marlow wrote:
> 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.
I may be misunderstanding the transformations you have in mind, but how
do I tell whether A.B.C.f and X.C.f are the same thing?
Also, suppose I have the documentation for someone's package, and I'm
looking at a program that uses that package, but grafted in at some
unknown point in the hierarchy. How do I understand that program?
This seems quite different from search paths; all that matters is the
text of the modules concerned, not their location in the file system.