Re: Concurrency (was: RE: Re[2]: important news: refocusing discussion)

Malcolm Wallace:

"Simon Marlow" wrote:

...

(a) we're going to standardise concurrency anyway

Well, but that only begs the question, what *kind* of concurrency are we going to standardise on? e.g. Will we admit all variations of scheduling (co-operative, time-slice, and pre-emptive)?

...

(b) it is unlikely that Hugs or JHC will implement concurrency even if it goes into the standard

Now this is something that puzzles me. I was under the impression that Hugs already implements concurrency, using pretty much the same APIs as ghc.

Hugs implements (part of?) the API, but it only implements purely co-operative concurrency (ie, thread switches only happen when Concurrency operations, such as takeMVar, are invoked).

...

Yes there are several ramifications of this decision, but none of them are technical. As I see it, we either specify Concurrency as an addendum, or NoConcurrency as an addendum, and both options are about the same amount of work.

There are certainly technical questions. If Hugs's implementation of concurrency is not concurrency after all, on what basis do we make that determination? Why is a definition of concurrency that encompasses both ghc and Hugs models unacceptable?

Because Hugs only supports co-operative scheduling. IANAJE[*] but I think that this is what Java did and regretted. It means that "standards conforming" concurrent programs have to work under all scheduling models allowed by the standard (if they want to be portable), which means there won't be many such programs - which in turn defeats the purpose of the exercise. In other words, if the standard is not restricting the admissible behaviour of implementations sufficiently, its going to be hard to write many useful programs against the standard. Manuel [*] I Am Not a Java Expert