[Haskell] Hierarchical module namespace
simonmar at microsoft.com
Wed Mar 9 18:09:26 EST 2005
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. 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.
> 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
> 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
>> 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!
More information about the Libraries