I tend to think this is a really bad idea. Although things get messy and there are plenty of corner cases, it seems to me the current system, haphazard as it is, is closer to the "right way." If, e.g., I want a Maybe transformer, I want to import it from Control.Monad.MaybeT, not from Lib.MaybeT. That way I can sort my imports sanely and see all my Control things in one place, no matter their provenance, all my data structures in another, be they from collections or bloom filters from hackage, etc. The other problem is that either everything eventually goes under lib, which creates the same problem again, or there is an implicit set of exceptions for things which, although not part of the official libraries (which we're trying to reduce, remember) are obviously too "standard" for lib (e.g., HTTP, and such). The problem here is that maybe this doesn't scale, since it requires hackage contributors to think about the package namespace as a whole, and some vigilance in that regard, the need to mark packages as depreciated properly, etc. But on the other hand, arbitrary namespacing leads to fragmentation, with everyone reimplementing things under their own hierarchy, and encouraging uses of standard(ish) namespaces also contributes to a mindset where people will pare down packages into lots of little reusable conceptual units that only do one thing well. The problem -- duplication of functionality and fragmentation -- is a real one, but dealing with it through throwing namespacing to the wind won't solve the underlying issues, which I think need to be addressed though the Haskell community guiding the direction of various efforts, and not through an artificial measure that makes fragmentation less immediately painful while doing nothing to mitigate the long term consequences. --S On Aug 18, 2008, at 7:32 PM, 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.
This would not require packages to *use* this namespace. However, packages that do use it would have a greatly reduced chance of conflicting with other packages.
Implementation costs are minor. At most, we might want some code in Hackage to prevent packages from using module names reserved for other packages. At the least, all we need to do is add "Lib" to the list of allowable top-level module names. Developers who object to giving the provenance of a module in its name are free to take their chances with the rest of the module hierarchy.
Mapping package names to module names is mostly straightforward. According to the Cabal documentation, a package name consists of one or more alphanumeric words separated by hyphens, where each word contains at least one letter. Since hyphens aren't allowed in module names, they would get mapped to underscores, which are not allowed in package names. Thus, "Lib.Foo_Bar" would be reserved for package "Foo-Bar".
It's less obvious what to do with packages whose names start with lower-case letters or digits. I see three possible solutions:
(a) Do not reserve module names for these packages.
(b) Map these package names to module names in a way that avoids conflicts, e.g., prefixing the package name with "P'", which cannot occur in a package name. That is, package "foo" would get "Lib.P'foo".
(c) Change the rules for package names on Hackage by disallowing package names which start with a digit or which differ from an existing package only in the case of the first letter, and reserve module names based on capitalized package names. That is, package "foo" would get "Lib.Foo", and Hackage would not accept a new package "Foo" if there was a preexisting "foo", and vice versa.
My preference is for (c). In fact, I might go further and forbid any package whose name differs only in case from an existing package in Hackage.
Further thoughts:
(1) I chose "Lib" because it's short and, so far as I know, unused. "Hackage" might be a better choice, since the scheme depends on Hackage to prevent name collisions.
(2) It was surprisingly difficult to find out the rules for valid package naming. None of the tutorials I found discussed choosing a valid name. The GHC documentation mentions that package names must have a specific form, but I couldn't find any description of it.
(3) I did not find a definition of "alphanumeric" in the Cabal documentation. Does this include non-ASCII characters?
(4) We could also reserve additional module names corresponding to specific versions of packages, e.g., "Foo-1.0" might get "Lib.Foo_1_0". This does not create ambiguity, because "Foo-1-0" is not a valid package name. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries