From: wren ng thornton
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.