RE: [Haskell] Hierarchical module namespace extensionnotsufficiently flexible

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

On Wed, 9 Mar 2005 09:53:35 -0000, Simon Marlow 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