Proposal: Reserved module namespace for packages on Hackage

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Mon Aug 18 21:24:26 EDT 2008


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



More information about the Libraries mailing list