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