GUI Library Task Force

[Tim Sauerwein]

"S. Alexander Jacobson" wrote:

> 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.

May I add my vote of agreement.

The concurrency abstractions in the GHC libraries are very fine indeed.

However, a GHC thread calling into the non-Haskell world blocks
all other threads until it returns, and experiment suggests that non-Haskell
threads calling into the GHC world are unable to interact freely with
other GHC threads.  Forging a peer relationship between Haskell and
non-Haskell threads would enable whole new classes of applications.
For example, a Haskell thread could call into the OS and wait for the
next GUI event, and a Haskell IO action could be registered with the
OS for callback when certain GUI events occur.

-- Tim Sauerwein / Galois Connections Inc.