[Haskell] Hierarchical module namespace extensionnotsufficiently flexible

[Iavor Diatchki]

Hello,

On Wed, 9 Mar 2005 23:09:26 -0000, Simon Marlow <simonmar at microsoft.com> wrote:
> 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
I am not sure if it is a good idea either.   There indeed was a bug in
the last example of both (2) and (3), the imports should both have an
"as T" in the end.

The difference between (2) and (3) is what _unqualified_ names get
introduced in the importing module.   In (2) one would get unqualified
names as usual, but the qualified names would have an additional
prefix.  In (3) there is no way to get unqiualified names at all.  I
am not sure that there are situations where (2) is neccessary, but I
don't think this effect can be achieved using only (3).  I agree that
we should perhaps go with the simplest and only have alternative (3).

> Yes, the qualified keyword is necessary to distinguish 'qualified module
> M' from 'module M' in the export list - they would mean different
> things.
You are right.  I was thinking that we could use the "as" for this
purpose, but perhaps programmers would often have to write things like
"module A as A" which seems more confusing than simply "qualified
module A"

> It sounds like you're supporting the addition of a 'hiding' clause for
> module exports?  I was actually advocating the opposite!
Well, I find that having something like "hiding" is useful in the
situations I described.
I was agreeing with you that perhaps the non-hiding versions, e.g.
module A(f,g) are not very useful, but perhaps should be there for
symmetry.   As you mentioned this is important when you want to talk
about the current module, and even if GHC supported modules that
import themsleves I don't think this would achieve the desired effect,
at least if recursive modules have the semantics that we presented in
the paper in the Haskell workshop a couple of years ago.

-Iavor