| Well, as an author of the Hierarchical Modules addendum, and as a | compiler maintainer, I am already reasonably convinced of the utility | of this suggestion. It does significantly alter the semantics | of import/export, in a way that the original Hierarchical Modules | addendum does not, but as Iavor pointed out, this is not necessarily | a bad thing. | | What we now need is a precise definition. After that, contributions | of code to implement it would also be welcome. :-) Simon and I agree. If someone is willing to evolve a detailed design, presumably based on the current Hierarchical Modules addendum, and that design met with general consent, we'd implement it in GHC. (Provided it didn't require massive changes, which would probably form part of the design criteria.) My current design is sketched below, but I have not thought about it as long as others have. Simon Syntax: Extend the export syntax to allow, as an export item, qualified module M [( ...items... )] [as N] Examples: module P( qualified module Button ) where import GTK.This.That.Button as Button module Q( qualified module GTK.This.That.Button as Button ) where import GTK.This.That.Button module R( qualified module Q( f,g ) ) where f = ...; g = ... Semantics. The effect of an export item 'qualified module' is to expose some qualified names as well a unqualified ones. That is the only way to expose qualified names. The rules on import are just as now. For example import P -- Exposes P.Button.new, Button.new import qualified P -- Exposes P.Button.new import qualified P as MyP -- Exposes MyP.Button.new That is, the names exposed by the exporter are imported with or without an extra qualifier, depending on the form of the import.