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.