GUI Library Task Force
Wed, 26 Sep 2001 09:23:15 -0700
"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.