On Mon, Mar 27, 2006 at 09:36:28AM +0100, Simon Marlow wrote:

On 26 March 2006 03:44, Ross Paterson wrote:

...

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

Sure, I think this is a point on which we're all agreed.

The portable interface could be Control.Concurrent.MVar, perhaps.

As Malcolm pointed out, using MVars requires some care, even if you were just aiming to be thread-safe. Packaged things like atomicModifyIORef are safe, but awkward, and need extra stuff to handle multiple variables. How about STM (minus retry/orElse) and TVars as the portable interface? They're trivial for a single-threaded implementation, and provide a comfortable interface for everyone.

Simon Marlow:

On 26 March 2006 03:44, Ross Paterson wrote:

...

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.

Yes, I don't see an easy way to do it. You could have one OS thread per Haskell thread (let the OS manage the separate C stacks), a giant lock around the interpreter (to protect all the global state), and explicit yield() from time to time to simulate pre-emption. This isn't too bad, but you still have to implement GC somehow, and hence traverse all the live C stacks, and that sounds tricky to me.

True, but so what? I mean, honestly, we should decide language features by their merit to applications and maturity. We should also take into account what the power/weight ratio of a feature is in terms of general implementation costs. But discussing the costs to one particular implementation that's already been stretched light years beyond what it originally was intended for, seems a bit much. Manuel