Heirarchical name space allocation

[Simon Marlow]

> That's no contradiction to my rule, e.g. 
> Graphics.Rendering.OpenGL is about
> *all* OpenGL stuff, while Graphics.Rendering.OpenGL.GL is about GL and
> Graphics.Rendering.OpenGL.GLU is about GLU.
> 
> Perhaps I should explain a little bit more what IMHO is a 
> "good use" of the
> hierarchical structure:
> 
>   * "collector" modules: These are a necessity for larger 
> APIs, otherwise you
>     can easily have dozens of closely related imports. Nobody 
> argued against
>     this use, IIRC, and we already have a lot of examples of it.
> 
>   * "selector" modules: There are different implementations 
> Foo.A and Foo.B of
>     basically the same API, but it's not clear (yet) which 
> one is better. So
>     Foo simply re-exports one of Foo.A and Foo.B as the 
> default for people who
>     don't care, but there is still the possibility of using a 
> specific one.
>     Text.PrettyPrint is an example of this use, although 
> there's currently only
>     one specific implementation. Another example is 
> Data.STRef, Data.STRef.Lazy,
>     and Data.STRef.Strict, but the imports are a bit 
> "upside-down" here, something
>     we should probably change.
> 
>   * A collection of only loosely related modules Foo.A, 
> Foo.B, ...: Having a
>     module Foo wouldn't make much sense in this case. A good 
> example for this
>     is the Data hierarchy.

There is a rough policy, which pretty much repeats what Sven says above,
here:

http://www.haskell.org/hierarchical-modules/libraries/layout.html

This is part of the document in fptools/libraries/doc/libraries.sgml,
BTW.  Some bits of it are out of date.  Perhaps I should separate out
the design guidelines into a separate document.

Cheers,
	Simon