I vaguely recall a brief discussion of this long ago, but don't see any reference to it on the libraries web page. What I had in mind is something like:
package Graphics.GL module Foo (...) where
import X import Bar.Y import Z ...
where the first conversion is
module-name <- package-name ++ "." ++ module-name
the larger issue would be how to convert imports to qualified imports (and module exports to qualified exports). i think (only my opinion) that something like:
import X
should be qualified to
import Graphics.GL.X as X
unless Graphics.GL.X doesn't exist, in which case it gets defaulted to
import X
This is an interesting suggestion. However, I'd like to see if people really think that writing out the full module names is really a problem in practice - in my (limited) experience with the hierarchical libraries so far I don't mind writing out the full module names in import lists at all, and I even quite like to see the module names written out in full. On the other hand, I haven't been working with any modules that go more than 3 deep in the hierarchy, so I'd like to hear feedback from someone writing a library with multiple modules that lives deep in the hierarchy (Sven - perhaps you qualify with Graphics.Rendering.OpenGL.GL?). But I guess the packages concept helps when you want to graft a subtree of modules from one place in the hierarchy to another, right? I must admit I don't like the idea of defaulting to importing X if <package>.X doesn't exist, I'd prefer the two cases to be syntactically distinct. Perhaps the convention should be that '.X' means '<package>.X', and plain X is left alone. (oh, and there have been various other suggestions along these lines - have a look back through the mailing list archives). Cheers, Simon