Proposal: module namespaces.

Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Tue, 27 Feb 2001 12:02:51 +0000


Ketil Malde writes:

> >     instance, either the fully-qualified or abbreviated-qualified names
> >             Text.Xml.Parse.element
> >             Parse.element
> >     would be accepted and have the same referent, but a partial
> >     qualification like
> >             Xml.Parse.element
> >     would not be accepted.
> 
> Why not?

I suppose it would be possible to have an implicit

      import A.B.C.D.E as E
      import A.B.C.D.E as D.E
      import A.B.C.D.E as C.D.E
      import A.B.C.D.E as B.C.D.E

To me, this seems like it introduces extra complexity with little
benefit for ease of use.  Wouldn't it be confusing to use C.D.E at
some places in a program, and D.E at others?  It isn't necessarily
obvious that they refer to the same entity.  After all, what if
your project has a module hierarchy like:

    A/B/C/D/E
    B/C/D/E
    Z/B/C/D/E
    R/S/T/D/E

?  To which of these paths might D.E refer?  No, I think that
restricting the implicit 'as' declaration to the simplest convenient
case (just the last component) is the best compromise to improve
readability, without introducing too many potential pitfalls.

And of course, you can always give an explicit 'as' clause if you wish.

> Perhaps one could have a warning/error if there are multiple "Parse"
> modules? 

This is kind-of what currently happens in Haskell'98.  You can rename
two imports to the same qualifier:

    import A as M
    import B as M

Provided that function f appears in only one of A or B, the qualified
name M.f is resolved correctly.  If function g is defined in both, then
M.g is ambiguous and the compiler gives an error - but only if you
actually mention M.g.  It is okay for A and B to have overlapping
definitions provided you don't try to use one of them.

> Personally, I'm not overly enthusiastic about using (.) for function
> composition - but I guess e.g the degrees sign was ruled out since
> it's not in (7bit) ASCII - and I think it should require spaces
> anyway, in order to differentiate it from its other uses.

I have been thinking about defining centred dot   in nhc98's Prelude
as a synonym for the composition operator.  Perhaps other Haskell
systems might be prepared to do the same?  (On my system I can type
a centred dot easily with the sequence Compose-dot-dot.)

Regards,
    Malcolm