GUI Library Task Force

[S. Alexander Jacobson]

On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
> > Given that Haskell98 is not ready for libraries anyway, why are you so
> > concerned about it?
>
> It isn't?  Why?  Because of the lack of hierachical name
> spaces?  Then, C isn't ready for libraries either.

As I posted in a prior thread:
* Library namespace is broken
So is C's, however it relies MUCH more strongly on build tools like
Make.  All popular languages that have been created in the last 20 years
appear to have saner systems (Java, Perl, Python, etc).  The problem is
worse in Haskell because the number of built in libraries is very small
and the code reuse goals are much more ambitious.

* Library Interfaces
This is a much bigger issue for Haskell than C.  Are they monadic and
which monad and should they really be arrows but then they will rely on
non-standard syntax, etc.

> > A GUI system without concurrency is still incomplete.
>
> There are loads of large GUI-based applications out there
> that don't use concurrency.
>
> BTW, my point was not to say that we rule out concurrency.
> I said, we do not demand it.  (Same as in many GUI libraries
> for the most widespread imperative languages.)

Haskell will not be production quality without concurrency.  If concurreny
allows for a cleaner API and easier to use library, then use it.  BeOS had
deep concurrency throughout and was a much better OS as a result.  Its
2001, there is no reason I shouldn't be able to have two threads drawing
things on the screen simultaneously.

If the issue is that we still don't know how to do concurrency in
Hasskell, that seems like a MUCH higher priority than sorting out GUIs.

> > The haskell library interface story is still pretty weak because there is
> > no consensus about what monad they should expose (and whether they should
> > really expose arrows or something else).   Why not focus on rolling from
> > H98 into a production quality Haskell system and make the best GUI for
> > that system?
>
> Currently, there doesn't seem to be much interest in going
> for a completely new version of Haskell.  The idea of adding
> addenda to H98 and so slowly and in incremental steps move
> to more functionality seems to be more popular.

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

Addendum .5?: Parametrized Libraries
Addendum 1: Hierarchical Library Namespace
Addendum 2: Concurrency
Addendum 3: FFI
Addendum 4: Exceptions
Addendum 4.5?: Proc Syntax for Arrows
Addendum 5: Library Interface Compatibility Guidelines
Addendum 6: Enumeration of standard Haskell libraries (GUI etc)

If we could focus on converging these addenda rapidly and in a particular
order, then Haskell could reach a much better place much more quickly.
Many of these things are individually small changes from H98, but
together they make it a much stronger language.

-Alex-

PS I don't know if this agenda is in the right order.  I do think that
everyone randomly thrashing about with different language features will
make everything take much longer.

___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-646-638-2300 voice                    The Easiest Way To Shop (sm)