On Sat, Mar 25, 2006 at 05:31:04PM -0800, isaac jones wrote:
I have no idea if it would work, but one solution that Simon didn't mention in his enumeration (below) is that we could find a group of people willing to work hard to implement concurrency in Hugs, for example, under Ross's direction.
I'm no expert on Hugs internals, and certainly not qualified to direct such an effort, but I don't have great hopes for it. Apart from the fact that Hugs is written in a legacy language and uses a quite a bit of global state, it also makes heavy use of the C stack, and any implementation that does that will have trouble, I think. I think it's clear that the proposed concurrency model is feasible for some implementations but not for others. I've been assuming that Haskell' was intended to encompass a wide range of implementations. If that's the case, the key point is that a Haskell' module that does not use concurrency, but is thread-safe, ought to work with non-concurrent implementations too. To make that work, we'd need two interfaces: * one for applications that make use of concurrency. This would be unavailable on some implementations. * one for thread-safe use of state. This would be available on all implementations, and authors not requiring concurrency would be encouraged to use it for maximum portability.