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.