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