Name allocation

[Simon Marlow]

=20
> Simon Marlow writes:
>=20
>  > The only way (currently) to have such a guarantee is to use
>  > User.To.Cryp.Simons as the root of your library tree.
>=20
> Does this really guarantee uniqueness?
>=20
> What if I don't own a domain name personally? What if I give up
> my domain and somebody else buys it?

True.

> What if somebody doesn't
> know of this convention and simply uses this exact name because
> he likes it?

Then libraries distributed without following the convention risk
colliding with other libraries on the system, and modules in a program.

> As far as I can tell, you cannot guarantee unique names at all if
> your name space system has an absolute root -- like Haskell does.
> Whatever you come up with may potentially clash with someone
> else's name -- and probably will. :-)
>=20
> The only way to guarantee unique names -- without requiring
> people to abide to some "arbitrary" convention -- is the module
> names to be relative. If I import a module "Foo.Bar", and I am
> "Peter.Simons.ToolXY", then this module will be
> "Peter.Simons.Foo.Bar" for me. In such a system I can uniquely
> access any module, no matter how it's called.

There's a technical problem with this: when we compile a module we bake
its module name into the symbols exported by the object code.  So this
approach would work fine for distributing source code, but not for
binaries.

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.  Certain packages are designated as "standard" so that you don't
have to specify the GUID (eg. the Prelude and standard libraries).  This
way you could have multiple versions of a package installed, and GHC
could provide backwards-compatibility packages so that programs written
for previous versions of the libraries continue to work.

Thoughts?  Would this be too ugly?

Cheers,
	Simon