GUI Library Task Force

Simon Marlow
Wed, 26 Sep 2001 16:29:46 +0100

> Thats great.  I don't disagree.  Its just a matter of priority.
> So how about this agenda?

Careful: we're in danger of not getting *anything* done if we try to
prioritise the tasks like this.  I think it's far more important to just
have one complete GUI system that everyone can use, even if it isn't
perfect.  I'm absolutely in favour of the current GUI effort.

So, when the hierarchical libraries come on-line then we'll have to
rename the modules of the GUI library to place them in the hierarchy.
That's not a big deal, since we're going to rename all our other library
modules too.

> Addendum 1: Hierarchical Library Namespace

The extension is virtually finalized and all the compilers implement it.
However, there's the much bigger task of actually moving over to using
the hierarchically organised libraries; this effort is ongoing.  We
intend to move GHC over for the next version, but leave some
compatibility libraries in place.

> Addendum 2: Concurrency

Hasn't changed much in ages, and largely independent of the others
(apart from module name differences with the library hierarchy).
Consider GHC's implementation as a draft proposal for a report adendum.
I plan to write up a proper proposal at some point (although if someone
else were to volunteer, I wouldn't complain :-).

> Addendum 3: FFI

Almost finalized.  Again, independent apart from module names.

> Addendum 4: Exceptions

Consider GHC's implementation a proposal, but omit the asynchronous
exception support.  Hugs (in CVS) implements nearly the same interface.

> Addendum 4.5?: Proc Syntax for Arrows
> Addendum 5: Library Interface Compatibility Guidelines

The document we've been drafting for the new library organisation has
the beginnings of a set of guidelines, and contributions are of course

The point I'm making is that we can parallelise these tasks to a certain
extent, and that doing so is essential in order for us avoid bottlenecks
and to converge at all.  I agree with many of the points you raise about
Haskell needing these features in order to be an "industrial strength"
language, but saying things like "we must wait for X so we can do Y
properly" has historically not resulted in X appearing in a timely
fashion, which in turn leads to no Y at all.

Manuel has done a good job of specifying the job of the GUI task force
so that it doesn't depend on any of these other tasks, and I think
that's the right way to go.