On Mon, 2008-08-18 at 19:32 -0400, David Menendez wrote:
In the interests of reducing module name collisions, I suggest reserving part of the module name space for individual packages on Hackage. Specifically, I'm suggesting that a new top-level module name, "Lib", be added to the module naming conventions, and that the children of "Lib" be reserved for the Hackage package with the same name. That is, "Lib.Foo" and "Lib.Foo.*" would be reserved for the package "Foo" on Hackage.
Note that this is entirely contrary to the existing (and well established) convention of naming according to the purpose / content of the module rather than the name of the implementation. What I mean is, it's a significant change. I'll throw in my opinion too. :-) I don't think it's necessary. The existing recommendations on naming mean we already don't get too many clashes, eg we get Database.HDBC and Database.HSQL. Even when names do clash they're typically implementations of similar things and how many packages need both at once? It's more common to pick one implementation of some functionality. It would certainly be interesting to make a service on hackage to work out what packages do have clashing names so that maintainers can work out with each other how to resolve things. For example suppose we have two packages implementing Text.PrettyPrint then we'd ask both to use Text.PrettyPrint.ImplName. If we allowed overlap in the modules exported by the packages in use then both can still export Text.PrettyPrint that just re-exports Text.PrettyPrint.ImplName. That way one can pick and no existing code breaks. So far in practise it seems that overlap is a pretty minor problem and could easily be resolved in most instances with just a little communication. It's not obvious that we need something much more heavyweight. If we really do need more then package-qualified imports is probably a better approach than a big change in module naming conventions. Duncan