Re: Proposal: Reserved module namespace for packages on Hackage

Hello, I also don't think that we need to prefix everything with Lib. However, I also do not like the current style of naming library packages, where a single package can sprinkle modules all over the hierarchy because: - It makes it hard to figure out where modules come from (e.g., when I see an import in the source code, it is hard to tell what library it came from), - The reverse problem also holds---when you look at the docs, it is hard to tell which modules are provided by a given package, - It discourages diversity (which some people may say is a good thing :-). What I mean is that there is a kind of "land rush" to stake out the good names in the hierarchy (I know that multiple packages can provide the same module, but it is still a pain, especially if you want _some_ modules from two conflicting packages). - I don't think the system scales that well. For example, if I was to create a package that draws graphs, should I put it under Data.Graph, and hope that no one uses both it, and the graph modules. And does that mean that to pick names for my modules I have to know all the modules in all libraries out there? - There are much better ways to classify modules by their purposes than the single hierarchy imposed by the module name space (think labels, tags, categories, keywords, all the usual ways people use on the internet to classify things). I think that it is a much better idea to use the package name as the top-level module name space, as we have already put some effort in ensuring that these are more or less unique. -Iavor On Mon, Aug 18, 2008 at 8:48 PM, David Menendez wrote:

On Mon, Aug 18, 2008 at 9:24 PM, Duncan Coutts wrote:

...

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.

Is it?

Look at the XML category at Hackage.

formlets - no common prefix generic-xml - all modules prefixed with Xml HaXml - every module is prefixed with Text.XML.HaXml hexpat - both modules are prefixed with Text.XML.Expat HXQ - one module, prefixed with Text.XML.HXQ hxt - 95 of 113 modules are prefixed with Text.XML.HXT libxml - all modules prefixed with Text.XML.LibXML tagsoup - 7 of 8 modules prefixed with Text.HTML.TagSoup xml - all modules prefixed with Text.XML.Light

Selecting things semi-randomly from the parser category, I see:

attoparsec - all modules prefixed with Data.ParserCombinators.Attoparsec binary - all modules prefixed with Data.Binary binary-strict - all modules prefixed with Data.Binary.Strict bytestringparser - all modules prefixed with Data.ParserCombinators.Attoparsec PArrows - all modules prefixed with Text.ParserCombinators.PArrow Parsec - all modules prefixed with Text.ParserCombinators.Parsec parsely - all modules prefixed with Text.ParserCombinators.Parsely polyparse - no common prefix uulib - all modules prefixed with UU

To me, it looks like a common pattern is to give most or all of the modules in a package a common prefix consisting of a general classification and the package name (or a close variant). All I'm suggesting is to give library authors the option to drop the classification part. Trying to create a collaborative, hierarchical classification system is a sucker's game. That's why Hackage itself uses tags.

-- Dave Menendez http://www.eyrie.org/~zednenem/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries