RE: [Haskell] Hierarchical module namespace extensionnotsufficiently flexible
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.
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".
Yes. 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.: module A ( qualified module B (f,g) ) where import B rewrites as: module A ( qualfied module B' as B ) where import B (f,g) as B' import B and I'm sure you can see how to rewrite the others. Sure, the first version is more readable, but I question whether we need the extra generality. It's extra rules in the syntax and extra work that the implementation has to do. 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). Cheers, Simon
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
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
participants (2)
-
Iavor Diatchki -
Simon Marlow