Top Level

[John Lato]

> From: wren ng thornton <wren at community.haskell.org>
>
> I think at this stage in the game, OpenGL.* is probably better. The way
> I see it there are two rather different kinds of modules (or module
> collections):
>
> * For module collections which have high utility across many different
> packages/programs (e.g. Data.Map, Control.Monad), having
> functionality-based names is helpful for solving name-clash and
> functionality-discovering/remembering issues. These modules are truly
> stand-alone "libraries" and are extremely composable (with other module
> collections) and extremely decomposable (from module collection into the
> constituent modules).
>
> * However, there are other collections of modules which are not
> "libraries" so much as "frameworks". While they're still (usually)
> composable, they're typically not decomposable. Often these are the
> results of taking an executable and shaving off some of the front-end
> details. Because of the non-decomposability, it makes sense to me to
> give each of these a top-level module name. Under the top-level they
> should be organized by functionality--- in the terms of the framework
> itself, not in the general terms shared by the "libraries".
>

+1.

For me, the largest problem with the current system is one that Simon
mentioned under his third point.  While I may know what to expect from
a module named "Control.Functor.Pointed", I have no idea what package
to import to get that functionality.*  This situation is worse in the
cases of multiple packages providing the same modules, such as
transformers and mtl.

I do think that the module namespace hierarchy is useful, and I am not
convinced that the top level should be flattened, but I think it would
be good to have some sort of tighter connection between package name
and either the top level or second level module name, even if only as
a convention.

John Lato
* I actually do know, because it's my example.  It's in
category-extras.  I was able to find this in Hayoo!, but not Hoogle.