Proposal: Reserved module namespace for packages on Hackage

[Iavor Diatchki]

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 <dave at zednenem.com> wrote:
> On Mon, Aug 18, 2008 at 9:24 PM, Duncan Coutts
> <duncan.coutts at worc.ox.ac.uk> 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 <dave at zednenem.com>
> <http://www.eyrie.org/~zednenem/>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>