Proposal: Reserved module namespace for packages on Hackage

[Sterling Clover]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries