[Haskell] Re: Top Level

[wren ng thornton]

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