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