| The thing that really annoys people is when some package they're using | internally uses some random utility module eg "C2HS.hs" then they cannot | use that same module name in their program. This is the case even when | the functions from that little utility module is not exposed in the | interface of the package. Yes -- but remember that what is exported from one package may become an internal detail of another. | detail but it exposed the cairo api directly to user programs. Now I | believe that with the ELF linking format it is possible to set things up | such that if you link with Gtk+ (which links with libpng) you can still | use symbols in your top level program that are exported by libpng and | you will not get linker errors. Perhaps. But it's leans more on linker cunning-ness, which is often not very portable across platforms, in my limited experience. And the simple expedient of adding the package name to the "original name" does the job once and for all. So why not use the simple expedient, that relies on no linker magic, and has stronger properties than what you suggest? Of course the programmer never sees this! He just sets up a module name space in which when he says "import A.B.C" it's clear which module A.B.C he means. Simon