[Haskell] Hierarchical module namespace extension notsufficiently flexible

[Iavor Diatchki]

Hello,
It seems to me that there are 2 or 3 independend extensions proposed here:

1.  The one has nothing to do with qualified names, and allows
explicit enumerations in module-style exports,e.g.
module M (module A(f,g)) where ...
I think the semantics of this should be the same as for "module A",
except with an additional filtering that we only export those entities
whose original unqualified name matched "f" and "g".

Related to this, it might be nice to also allow "hiding" declarations
as well. Then we can write things like:
module M (moudle M hiding (f)) where...

2. Another proposal is to allow "as" clauses for "module"-style exports, e.g.
module M (module A as P) where ...
This gives an exporting module some control over how qualified names
in the importing module are constructed, e.g.  if "f" and "g" were
exported from "M":
import M as T -- introduces the names "f","g", "T.P.f", "T.P.g"
import qualified M as T -- introduces the names "T.P.f", "T.P.g"
import M(f) -- introduces "f", and "T.P.f"

3. Then we can also allow for "qualified" module-style exports which is what Sim
on wrote, e.g.
module M(qualified module A as P) where ...
This has a different semantics in non-qualified imports, and the way
explicit exports work:
import M as T   -- introduces "P.f", "P.g", "T.P.f", "T.P.g"
import qualified M as T -- introduces "T.P.f", "T.P.g"
import M(f)    -- error, M does not export "f"
import M(P.f)  -- introduces "P.f" and "T.P.f"

What do people think should happen in the following situation?
module N (module M) where
import M

Should the qualified names paired with the entities be lost or kept? 
Losing the  qualified names in this situation seems to be easier to
implement, but perhaps this is not what a programmer expects?

-Iavor



On Tue, 8 Mar 2005 16:02:38 -0000, Simon Marlow <simonmar at microsoft.com> 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.
> 
> Cheers,
>         Simon
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>