[Haskell] Hierarchical module namespace extensionnotsufficiently flexible

[Simon Marlow]

On 09 March 2005 18:34, Iavor Diatchki wrote:

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

I'm not in favour of this proposal, i.e. point (2) from your original
message[1].  I don't think I fully understand it: is there a mistake in
the last example of point (2)?  The other examples can be achieved in a
clearer way with a 'qualified module' export.

[1] http://www.haskell.org//pipermail/libraries/2005-March/003404.html

[snip]
> 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.

Yes, the qualified keyword is necessary to distinguish 'qualified module
M' from 'module M' in the export list - they would mean different
things.

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

It sounds like you're supporting the addition of a 'hiding' clause for
module exports?  I was actually advocating the opposite!

Cheers,
	Simon