[Haskell] Hierarchical module namespace extension not sufficiently flexible

[Duncan Coutts]

On Sat, 2005-03-05 at 18:40 +0100, Gour wrote:
> Duncan Coutts (duncan.coutts at worc.ox.ac.uk) wrote:
> 
> > Or as an alternative to exporting qualified names as I proposed before
> > (ie Graphics.UI.Gtk exports the qualified name "Button.label") how about
> > this:
> > 
> > import qualified Graphics.UI.Gtk.*
> > 
> > which just means import every module under Graphics.UI.Gtk qualified
> > with it's module name so that then you could reference:
> > 
> > Button.label
> > 
> > A downside to such a scheme is that it might make it too easy to import
> > internal modules or modules that are not supposed to be used together.
> 
> But does this option not contradict the argument against the 1st one,
> i.e. that one should know the internal structure, i.e. hierarchy of the
> lib in order to know what he is doing by importing everything?

In the first proposal:

        import Graphics.UI.Gtk
        -- which brings Button.label into scope

I don't need to know much about the internal layout of the library. I
only need to know that it exports the Button module or the Label module
etc.

There can be Graphics.UI.Gtk.Internal or Graphics.UI.Gtk.Types which
should not be directly imported by client code. Users need not know they
are there.

However if I can

        import qualified Graphics.UI.Gtk.*

or worse

	import Graphics.UI.Gtk.*

then it's possible that I could be bitten by unexpected name clashes or
something.

In the latter case it's the user who has the power and who has to be
aware when they use it.

In the former case the library author has the power and presumably we
can trust them to be sensible with it.

It does mean that as I library author I'm sort of forcing you to use
qualified names when perhaps you did not want to. But for some libraies
you really can't sensibly use them with a flat name space. There are
dozen different things in Gtk+ that have a 'value' property.

Duncan