On Tue, 2005-08-16 at 16:31 +0100, Simon Peyton-Jones wrote: > | First of all I want to thank Isaac Jones for his work on Cabal. > | > | There are a few issues I would like to raise. > > Seconded -- Isaac you are doing a great job. Yes, indeed. >. I think it might be possible to have something slightly weaker. So that modules which are used merely as an implementation detail may overlap with modules of the same name in another package or the top level program. The. Another nice example of this is when Cabal used to use a couple modules from the util-1.0 package. These modules were not exposed through the Cabal interface, they were purely an implementation detail and yet it meant that no program that used any of the cabal libs could have a GetOpt module (or one or tow other modules). On the other hand, when a module re-exports entities from other modules then those modules are in some sense exposed in the interface of the module/package. In this case it is much more reasonable that the global module namespace has been populated. As an analogy from C, Gtk+ uses libpng as a private implementation. What it does is link your program to Gtk but not to libpng, even though Gtk+ itself links to libpng. So in effect it draws a division in the collection of symbols in the program so that the same name may appear in two places so long as they are not directly linked. This only works because Gtk+ does not expose libpng in it's interface. Now on the other hand, unlike libpng which is a private dependency of Gtk+, cairo is a public dependency of Gtk+. Programs which use Gtk+ can directly use the cairo interface. So the ELF setup for the link between cairo and Gtk+ is different to that between Gtk+ and libpng. So you cannot reuse names from cairo without getting linker errors. I suggest that we can use the same concept (and possibly the same tricks with ELF linkage) for ghc's library packages. So we would need to distinguish between public and private package dependencies. This can be automatically checked by making sure no symbols from the private dependency are re-exported. They must be used only in the implementation. So the point is that we would never need to qualify names with the package they're from since it would never be possible to have both instances of the same name in scope at the same place (or if you do, it's because you directly imported it, in which case it's your fault). So my point is that I think we can eliminate the vast majority of the annoying module name clashes without having to go for a full "qualify everything with it's package" approach. We just need a concept of which module names a module or package exposes and make it possible to limit the modules which become exposed to those from which things are re-exported. (There is a technical difficulty with this which is that things can become re-exported due to inlining. It remains to be seen how the difficulty might compare to some grafting solution, which I suspect is not likely to play well with existing linker technology.) Duncan