[Haskell] Hierarchical module namespace extension not sufficiently flexible

Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk
Mon Dec 20 06:32:58 EST 2004

Duncan Coutts wrote:
> >So while we would like to be able for users to do this:
> >  
> >>import Graphics.UI.Gtk
> >>... Button.setLabel ...

You are right, it is impossible to do this form of qualification,
either in Haskell'98 or in the hierarchical namespace extension.

The libraries list has discussed this issue before, in its earliest
days, but I think this is the first truly compelling example I have
seen where a further extension would be desirable.

"Iavor S. Diatchki" <diatchki at cse.ogi.edu> writes:
> One possible extension that might solve this problem is to allow
> partial qualified names, i.e. a qualified name only specifies enough
> of the _ending_ of the full qualified name to make it unambiguous.

Whilst this is an attractive suggestion (and a variant has been
implemented in nhc98 since it first adopted hierarchical namespaces),
it does not solve Duncan's problem.  An abbreviated qualifier is
still dependent on using the module name from the /import/ statement,
and thus all imports must be named explicitly, if you want to qualify
their contents.

The desire is to use an abbreviation of the original /exporting/
module name, so that the exporting modules can be gathered together
into a single container for import.  Only one import statement is
required, but it brings many qualifiers into scope.

So it is beginning to look like the import/export mechanism needs
to add another kind of entity to the set of namespaces it already
handles (functions, classes, types, constructors, methods, fields,
+qualifiers).  On the plus side, this looks like a genuinely useful
addition.  On the minus side, import/export is already rather more
complicated than it looks at first sight - do we want to add even
more complexity?


More information about the Libraries mailing list