[Haskell] Hierarchical module namespace extensionnotsufficiently flexible

[Iavor Diatchki]

Hello,
In my previous mail I just outlined different options we had, I don't
know that we need to add all (or in fact any) of  them to the
language.

On Wed, 9 Mar 2005 09:53:35 -0000, Simon Marlow <simonmar at microsoft.com> wrote:
> On 09 March 2005 08:46, Simon Peyton-Jones wrote:
> 
> > 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.

Just clarifying what I meant here....  Adding an "as" would not be a
no-op.  Notice that in the example I wrote it changed what qualified
names got introduced to the importing module, but did not affect the
unqualified names.    This breaks the symmetry with imports a little
as these two are not the same:
module M (module A) where ...    (behaves as usual)
module M (module A as A) where ...   (this one would add "A" to
qualified names in imports)
which differs from the behavior of "as" on imports.

> > 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 therefore irrelevant if you
> > don't have "qualified".
This is fine by me.  If we want to just have the one possible meaning,
do we really need to
use the "qualified" keyword at all?  It seems to make things more
verbose, and I am not sure if the perceived symmetry with imports will
help or confuse programmers.

> I'd like to question whether specifying the entities in a qualified
> module export is really necessary.  Most examples can be rewritten using
> restricted imports instead, eg.:
> ...
> The exception (as Simon already pointed out to me) is when you're
> exporting entities defined by the current module, with a qualifier.  You
> can't rewrite that unless the implementation supports self-imports,
> which I believe is tricky to implement (GHC doesn't support it).

I agree with this at least to some extent.   I have often needed the
"hiding" version of these exports, e.g. when I'd like to export
everything from a module except a few private functions.
Currently I need to enumerate everything but the few functions.  I
guess I could introduce a separate module for these functions, but
this is not very nice.  Also without support for recursive modules
this will not work if the private functions need to use some of the
public functions.

I think that the two changes are independend of each other.

-Iavor