Libraries and hierarchies

Ganesh Sittampalam
Mon, 04 Aug 2003 12:24:02 +0100

On Mon, 4 Aug 2003 11:50:43 +0100, "Simon Marlow" <>

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

It also gives the advantage that modules can be moved in the hierarchy (by a
command-line flag or whatever) specifically to support whatever a particular
program happens to require. 

Would the following be possible under your proposal:

module M1.A imports Collections.Foo and only works with version 1
module M2.B imports Collections.Foo and only works with version 2
module C imports M1.A and M2.B

Could we compile/use M1.A with Graphics.UI mapped to Graphics.UI.v1 and M2.B
with Graphics.UI mapped to Graphics.UI.v2 and then correctly compile module
C? Being able to do this would cause problems for the type-equivalence you
mentioned elsewhere, of course.