[Haskell] Hierarchical module namespace extensionnotsufficiently flexible

Simon Peyton-Jones simonpj at microsoft.com
Wed Mar 9 03:46:13 EST 2005

| 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))

I agree.

| 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"

That wasn't what I intended (though it would be possible)  At present
	module M( module A ) where ...
does not cause qualified names in the importing scope:
	import M as T	-- introduces only f, g, T.f, T.g
Simply using "as" on the export clause would not change that, would it? 
In fact, as John M says, it'd be a non-op.

In short, my suggestion is that using "qualified" in an export list is
the *only*
way to introduce extra module qualifiers in an importing scope.  Using
"as" in
an export item would serve only to change what the qualifier is, and is
irrelevant if you don't have "qualified".


More information about the Libraries mailing list