Name allocation

[Keith Wansbrough]

Simon Marlow writes:

> One other approach is to do it the Microsoft way and give all libraries
> GUIDs, with the rule that you have to change the GUID when you change
> the library API.  This would guarantee no library clashes, because a
> module name would include its GUID.
> 
> Hmm, this might be a good idea.  Suppose in GHC we give each package a
> GUID.  You import a module by giving the package GUID and the module
> name.

If you use a hash of the API or of the module source code, you get
GUIDs that are automatically unique, and automatically change when
they are supposed to.  Furthermore, you don't need to distribute them
separately - anyone can compute the GUID if they have the source.

Hashing the entire source is a good idea, because functionality can
change even if the API doesn't (particularly, bug fixes that your code
might depend upon).

We wrote a paper about this, which is to appear in ICFP this year. See

http://www.cl.cam.ac.uk/~kw217/research/paper-abstracts.html#Leifer*03:Global

_Global Abstraction-Safe Marshalling with Hash Types_, James
J. Leifer, Gilles Peskine, Peter Sewell, Keith Wansbrough.

We're currently thinking about how to incorporate version numbers into
this scheme, likely along the lines of _Modules, Abstract Types, and
Distributed Versioning_, Peter Sewell, POPL 2001 (see
http://www.cl.cam.ac.uk/users/pes20/).

--KW 8-)