Heirarchical name space allocation

[Sven Panne]

Wolfgang Jeltsch wrote:
> Am Sonntag, 4. April 2004 16:51 schrieb Sven Panne:
>>I have a small brain and therefore I like simple rules like "Every module
>>Foo simply re-exports the modules Foo.*". :-)
> I've never used this strategy.  In my opinion, it makes much sense if a module 
> Foo is about general foo things whereas its submodules are about more 
> specific things.

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.

So I'm not that narrow-minded by supporting only a single rule... :-) But we
should really try to avoid a structure with no clear superset/subset relationship
like, alas, the Foreign module.

Cheers,
    S.