Hi Alastair, Thanks for the comments.
I wonder if the extra complication is really that high. Suppose that every module somehow has a unique name (128 bit hash, global registry, whatever) and that we have setup two mappings to the same thing:
Foo.Bar -> Reid.Consulting.Bar.version27 Baz.Bar -> Reid.Consulting.Bar.version27
to implement this in Hugs, it is _almost_ enough to simply run all source code through a preprocessor which replaces occurences of Foo.Bar and Baz.Bar with Reid.Consulting.Bar.version27.
Yes, this is a simpler implementation.
(b) needing unique package names,
The original proposal tied this feature strongly to packages. I wonder if this is really necessary.
Perhaps not - we only use packages as a convenient notion for a collection of modules within which relative module names can be used, and as a way to identify the collection.
Putting that aside, it seems that unique package names are fairly easy to come by. Some possibilities are:
1) Use the URI of the primary download site. From choice, the URI would be for a tarfile or whatever but all that really matters is that it is unique. This will typically include a version number but, if not, the user could add one if they care.
2) In the likely event that we have a few big repositories and many small ones, simply prefix the name of the package by the repository name or, if not available, name of author. This is effectively the same as (1) but avoids using URIs.
3) Directory name on your system.
We can't use (3) in GHC, because the package name has to be fixed at compile time, and can't be changed once the binaries have been generated. It's an advantage to have short package names, because (at least in GHC) the package name will be included in every symbol in a compiled library. URIs are attractive, but long. It will make debugging really painful. Another scheme would be to use short package names (eg. "gtk-0.15", "hgl-3.00"), and have a web page (eg. on the Wiki) where everyone can register package names, with links to the appropriate download sites. This works well for the Python folks, and I think having short, readable package names will make the whole scheme more accessible. --- Some notes on dependencies, which occurred to Simon & I: An interesting property of this scheme is that if you distribute a binary library, then you only have to list the package names on which it depends: it doesn't matter where in the hierarchy the packages are sited on the target machine, it will still work. If you distribute source code, then the dependency list must include both package names and sites; this is something that can easily be incorporated into Isaac's distribution toolkit. We need an easy way to set up the system with the correct packages & sites for compiling some code, but that shouldn't be too hard. Interestingly, this is another way that source code can unambiguously refer to libraries: by package name, site, and module name (with the former two properties being specified out-of-band in some additional matter that comes with the source code - perhaps a package specification or similar). This is rather less ugly than using GUIDs. We can also provide GUIDs, of course, because doing so is cheap. Cheers, Simon