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 welcome. 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. Cheers, Simon