Libraries and hierarchies

[Simon Marlow]

=20
> > Modules in other packages can be imported only by uttering=20
> their full
> > path names in the global hierarchy (of the compiler that is=20
> compiling
> > the package).
> i don't quite understand this part. how is a module going to import=20
> modules from another package, if it does not know where these=20
> packages=20
> are going to be installed?  if i am writing a module M, which imports=20
> A.B.X.N which is module X.N from a package P that was=20
> installed at A.B,
> doesn't that force everyone who is trying to use my package=20
> to install P at the same place: A.B?

Well, this is the key issue.

Standing back a moment, I see three alternatives to organising the
hierarchy:

  1. We have a global registry for module names.  The hierarchy is
     always populated with the same modules on every Haskell system.
     We have a mechanism for naming libraries after email addresses
     or domain names, or GUIDs, to ensure that everyone can get a
     non-clashing module name when they want one.

     This suffers from (a) needing a global registry for ordinary
     names (i.e. the non-GUID ones) and (b) overly long module names,
     (c) no library versioning.


  2. We have no global registry for module names.  Everyone is
     free to name library modules whatever they choose.

     In practice, groups of Haskell programmers will get together
     and maintain collections of non-clashing libraries, such as
     the fptools/libraries collection.

     This suffers from (a) possible name clashes between libraries,
     (b) no way to unambiguously refer to a specifiy library in Haskell
     source, (c) still no way to abbreviate long module names, and (d)
     still no GUIDs or versioning.


  3. As (2), but the full name of a module is not fixed in the source
code,
     and can be mapped into the hierarchy at multiple places.

     This is the method proposed in the message that started this
     thread.  Because modules can be placed in the hierarchy in multiple
     places, it gives a good way to add library versioning and
     GUIDs to libraries.

     This suffers from (a) extra complication in the implementation and
     specification of the language, (b) needing unique package names,
     (c) referring unambiguously to a specific library must be done
     by GUID.


So I guess what we're saying is that we're proposing (3) as a solution
to the problems of (2).  It probably isn't the best solution - indeed,
I'm still worried about the implementation difficulties and the fact
that we need unique package names, but perhaps solutions to these can be
found.

To answer the question, to unambiguously refer to another library under
this story, you must import it by GUID.

Cheers,
	Simon