Re: [Haskell] Hierarchical module namespace extension notsufficiently flexible

On Tue, Mar 08, 2005 at 04:02:38PM -0000, Simon Marlow wrote:

On 08 March 2005 15:39, Malcolm Wallace wrote:

...

"Simon Marlow" 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⑈