[Haskell] Hierarchical module namespace extension not sufficiently flexible

Benjamin Franksen benjamin.franksen at bessy.de
Sun Mar 6 15:23:36 EST 2005


On Sunday 06 March 2005 13:23, Duncan Coutts wrote:
> 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".

Ok, thanks for the detailed answer.

Cheers,
Ben


More information about the Haskell mailing list