On 08 March 2005 14:36, Simon Peyton-Jones wrote:

...

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 = ...

From the last example is looks like (... items ...) are understood in the context of the top-level scope of the current module. That looks a bit strange to me, because it's different from an import declaration where the (... items ...) are entities exported by the named module.

If we're going to allow (... items ...) at all, then I suggest instead that the last example be written: module R( qualified module R(f,g) as Q ) where f = ...; g = ... Cheers, Simon