[Haskell] Hierarchical module namespace extension notsufficiently flexible

[Simon Marlow]

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