Simon Marlow wrote:
Where does that leave module names? What are the advantages of having a rigidly-defined module hierarchy based on functionality classification? The only reasons I can think of are:
* Choosing module names based on some generally agreed-upon guidelines makes it less likely that one package's module names will clash with another.
+1.
* Packages that are conglomerations of different kinds of functionality (e.g. base) benefit from functionality-based module naming.
+1.
* Source code doesn't refer to packages, it only refers to module names. So if you're trying to understand a piece of source code, it helps if the module names it imports are descriptive and unique. On the other hand, a module name tells you nothing of the provenance or the version of the module it refers to, so arguably source code without its dependencies is already less than useful.
So why shouldn't OpenGL be naming its modules OpenGL.*, rather than Graphics.Rendering.OpenGL.*? Personally, I can't think of any sufficiently compelling reasons any more.
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". If many very-similar frameworks are anticipated (in particular, when more than one may be used in a single project), then it makes sense to collect them under a common top-level name. Test.* is a good example of this, though possibly the only one (or maybe Reactive.* as well). I'm not sure that I see rendering as a functionality that's sufficiently widely-used with many competing frameworks where more than one would reasonably used in a single project, in order to merit the Rendering.* prefix (but I don't play here, so I could be wrong). The Graphics.* prefix strikes me as too generic and unhelpful since it doesn't "mean" anything exactly: we could have an ASCII Art image renderer, should that be under Graphics.Rendering.* or Text.Rendering.*? -- Live well, ~wren