[Haskell] Re: Top Level
wren ng thornton
wren at community.haskell.org
Thu Jun 18 05:32:42 EDT 2009
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.
> * Packages that are conglomerations of different kinds of functionality
> (e.g. base) benefit from functionality-based module naming.
> * 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
* 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
* 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.*?
More information about the Libraries