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⑈