[Haskell] Hierarchical module namespace extension notsufficiently flexible

[John Meacham]

On Tue, Mar 08, 2005 at 04:02:38PM -0000, Simon Marlow wrote:
> On 08 March 2005 15:39, Malcolm Wallace wrote:
> 
> > "Simon Marlow" <simonmar at microsoft.com> writes:
> > 
> >>>   module R( qualified module Q( f,g ) ) where
> >>> 	f = ...; g = ...
> >> 
> >> 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 = ...
> > 
> > I initially understood the first form to mean something different,
> > although admittedly the original example does not actually illustrate
> > it:
> > 
> >       module R( f,g, qualified module Q( f,g ) ) where
> >         import qualified Q (f,g,h)
> >     	f = ...; g = ...
> > 
> > That is, the subordinate items mentioned in conjunction with the
> > qualified export are a subset of those imported from Q, not those
> > defined in R.  Within the subordinate clause of the export list, they
> > do not need further qualification since they belong unambiguously to
> > Q. 
> 
> Yes, I think we're all on the same page here.  That's my understanding
> of the meaning of 'qualified module Q(f,g)' too, and I think it's what
> Simon intended.

Formally, I think a reasonable rule is an export of the form

qualified module X as Y

exports all names n in scope for which n and X.n refer to the same
entity as Y.n.

this is exactly analogous to the current module X rule,  which is

module X 

exports all names n in scope for which n and X.n refer to the same
entity as n.

and sidesteps the issue of worrying about what was imported as what by
which import.

Although, I also like the other generalization mentioned, which allows
module X(foo) and module X hiding (foo) so the qualified and unqualified
exports are nicely similar.  


The only difference would be that it does not make sense to have an
unqualified 

module X as Y

since for unqualified module exports, the name does not matter.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈