[Haskell] Hierarchical module namespace extension not sufficiently flexible

[Duncan Coutts]

On Sun, 2005-03-06 at 01:29 +0100, Benjamin Franksen wrote:
> On Saturday 05 March 2005 20:06, Duncan Coutts wrote:
> > 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 libraries
> > you really can't sensibly use them with a flat name space. There are
> > dozen different things in Gtk+ that have a 'value' property.
> 
> I'd be interested to know why you don't use classes for that.

Because they don't share an interface or some common semantics. They
just happen to use the same name.

I don't think it's good design to use classes just because you want
ad-hoc overloading.

(We do use Haskell classes to model Gtk+ classes)

Indeed this isn't even overloading really, the Gtk+ system we are
wrapping uses a hierarchical module namespace itself (albeit in C
following the naming convention namespace_class_method). We are just
trying to model this in Haskell with Haskell modules. Every other
language binding for Gtk+ does this: C++, Java, Perl, Python, Ruby,
OCaml etc.

We can do it too except that to use qualified names, users would have to
import dozens of modules:
import Graphics.UI.Gtk.This
import Graphics.UI.Gtk.That
import Graphics.UI.Gtk.TheOther.

So at the moment we prefix the module name to everything in the module,
"buttonLabel" so we can export everything through Graphics.UI.Gtk
whereas we (and the designers of the hierarchical module namespace
extension) would prefer people to be able to use "Button.label".

Duncan