Name allocation

[Peter Simons]

Simon Marlow writes:

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

Yes, that's true. And unfortunately, there is little one can do to
remedy this situation without having support in the linker or without
having a pre-linking stage, which can add a prefix to the symbol names
after they have been compiled.

I know very little about ELF and other formats, though, so it's
entirely possible that modern linkers _do_ support this already. A
quick glance at the man page of GNU ld revealed the ELF fields
DT_AUXILIARY and DT_FILTER, which can be set with -f and -F
respectively and may provide a solution for this problem.

In any case, it would be extremely nice to have this capability
because it would really _solve_ the name-clash problem once and for
all. I'm sure it can't be _that_ hard to do.


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

I know next to nothing about this GUID concept, so please correct me
if I'm wrong, but isn't this GUID just "yet another unique identifier
convention", which may or may not clash, depending on how lucky you
are? Would using a GUID really be different than using a hierarchy
like Haskell does today?

Peter