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

newer
RE: Re[2]: important news:...

older
bringing discussions to a close

Simon Marlow

27 Mar 2006 27 Mar '06

9:36 a.m.

On 26 March 2006 02:31, isaac jones wrote:

...

Possible Interests: 1. I can write tools like filesystems, web servers, and GUIs in Haskell' 2. Libraries that I use are thread-safe 3. I can compile my code with any Haskell' compiler 4. Tools such as debuggers and tracers that claim to support Haskell' actually work on my code. 5. That there not be "too many Haskell's" 6. That there be a diversity of Haskell' implementations 7. That concurrency be reasonable to implement for existing compilers/interpreters. 8. That it be reasonable to implement for new compilers/interpreters. 9. Show off how effective Haskell can be in this area (possibly attracting new users).

By 5 I mean that it might be nice to have a "core" Haskell and a bunch of addenda. But this could cause no two Haskell' implementations to be the same. (My Haskell' might have concurrency and FFI, but no class system, or something.) The more optional addenda we have, the more we actually fracture the language. We could be in the same situation we're in today.

Isaac's Interests * 1-6, 9

Simon's Interests: * He's mentioned 9, I'm sure that there are others.

I'd count all of 1-9 as interests - they're all desirable. But we haven't found a design that satisfies 1-9, and in the absence of that we have to compromise somewhere. But before we get carried away figuring out all the pros and cons of various options, let me point out once again that This is just a marketing decision Because (a) we're going to standardise concurrency anyway (b) it is unlikely that Hugs or JHC will implement concurrency even if it goes into the standard (c) the question is just whether the "brand" Haskell' encompasses concurrency or not (I thought I'd use that word because I know JL likes it so much :-) 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. So on that note, I'll restate my preference that Haskell' should include concurrency, and leave it at that. We can start the standardisation process without arriving at a conclusion on this issue anyway. Cheers, Simon

Show replies by date

Malcolm Wallace

28 Mar 28 Mar

5:13 a.m.

"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. I'd also like to know a bit more about jhc's position here. Is it just that JohnM wants to keep his compiler "pure" and free from having a runtime-system? Or are there other issues?

...

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? Regards, Malcolm

Manuel M T Chakravarty

9:07 a.m.

New subject: 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

Ross Paterson

5:43 a.m.

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

On Mon, Mar 27, 2006 at 03:36:55PM +0100, Simon Marlow wrote:

...

This is just a marketing decision

Oh dear.

...

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.

I'm not sure what a NoConcurrency addendum would look like, since the target is programmers, not implementors. "Some implementations do not provide modules X, Y and Z."?

isaac jones

1:22 p.m.

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

On Mon, 2006-03-27 at 15:36 +0100, Simon Marlow wrote:

...

On 26 March 2006 02:31, isaac jones wrote:

...
Possible Interests: 1. I can write tools like filesystems, web servers, and GUIs in Haskell' 2. Libraries that I use are thread-safe 3. I can compile my code with any Haskell' compiler 4. Tools such as debuggers and tracers that claim to support Haskell' actually work on my code. 5. That there not be "too many Haskell's" 6. That there be a diversity of Haskell' implementations 7. That concurrency be reasonable to implement for existing compilers/interpreters. 8. That it be reasonable to implement for new compilers/interpreters. 9. Show off how effective Haskell can be in this area (possibly attracting new users).

(snip)

...

I'd count all of 1-9 as interests - they're all desirable.

Indeed they are all interests that I hold as well, some more than others, and I think it would be helpful to know how different people weigh different interests and why.

...

But we haven't found a design that satisfies 1-9, and in the absence of that we have to compromise somewhere.

If a single standard were the only option, then we'd have to satisfy some interests and not others, but if we are creative, we may find other solutions. Two such solutions have been proposed, one is that we use an optional addendum and the other is that we work hard to implement concurrency in Hugs. So you see, it's possible that we may not have to "split the difference" if we are creative. Here's a story to illustrate the difference between discussing positions (including pros & cons) and discussing interests:

...

Two children are arguing over an orange. “It’s my orange!” screamed one of the children. “No, it’s my orange!” yelled the other. Dad enters the room and decides to help the children out by cutting the orange in half and giving a portion to each child. But, neither child is happy. One of the children wanted the orange peel to make marmalade, while the other wanted the pulp to make juice.

"It's my orange" is the position while the interests are explained by the last sentence.

...

But before we get carried away figuring out all the pros and cons of various options, let me point out once again that

This is just a marketing decision

This assertion highlights a set of interests not outlined above: 10. compilers/interpreters may gain or lose popularity by declaring that they are 100% pure haskell (of course, they will have to be Sun certified ;) 11. Haskell itself may gain or lose popularity by "branding" itself as being good at concurrency (well, maybe that's the same as 9). What else are you talking abut when you say it's a marketing decision?

...

Because

(a) we're going to standardise concurrency anyway

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

(c) the question is just whether the "brand" Haskell' encompasses concurrency or not (I thought I'd use that word because I know JL likes it so much :-)

Yes there are several ramifications of this decision, but none of them are technical.

Actually, interest number 5 above is somewhat technical and relates to whether or not we make it an addendum. peace, isaac

John Meacham

29 Mar 29 Mar

4:16 a.m.

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

On Mon, Mar 27, 2006 at 03:36:55PM +0100, Simon Marlow wrote:

...

But before we get carried away figuring out all the pros and cons of various options, let me point out once again that

This is just a marketing decision

Because

(a) we're going to standardise concurrency anyway

concurrency is a hugely overloaded term in this whole discussion. I am hoping to break out what it actually means on the wiki some more.

...

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

Well, if the standard is unimplemented for certain compilers, I think we need to work on the standard because that would be a deficiency of it. I would very much like to be able to write portable concurrent programs which doesn't necessarily mean GHC style concurrency or nothing. given the choice between 1. a standard specifying something most people can't implement 2. a widely available but not mentioned in the standard extension 2 seems much more preferable and we should err on that side. of course, this is a false dichotomy as there are happy mediums in the middle I hope we can arrive at. I am thinking jhc will offer two concurrency mechanisms eventually, 1. state-thread based threading based on a portable user space library. so you get O'Haskell or hugsish concurrency by just using the right library. 2. one OS thread per haskell thread, no guarentees about repeated work between threads. the reasoning being that a programer can avoid the problem of repeated work by being clever, but the run-time cost of suspending partial evaluations and protecting in-progress computations is unavoidable. some profiling support will probably be needed to aid a programmer in determining if repeated work is an issue. I think it is very likely that hugs and jhc and yhc will all implement concurrency of some sort so it would be odd if ghc's happened to be the only one that is standards compliant by definition.

...

(c) the question is just whether the "brand" Haskell' encompasses concurrency or not (I thought I'd use that word because I know JL likes it so much :-)

I don't think it should necessarily, at least not a type of concurrency that can't be widely implemented. it would be "bad for the brand" and sort of negate one of the points of haskell' if GHC were the only true implementation.

...

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.

this is a big big understatement. the concurrency specifications are completly underspecified and there is a lot of technical work that would be needed to bring them up to snuff. the current proposal basically says "do what GHC does" in a lot of words.

...

So on that note, I'll restate my preference that Haskell' should include concurrency, and leave it at that. We can start the standardisation process without arriving at a conclusion on this issue anyway.

indeed. but I feel that just saying "GHC style or nothing" would sort of suck as there are very fruitful intermediate options without the caveats of the ghc model. I think we actually are going to need to dig into the details of concurrency, one way or another and I'd like to see something portable/good/and uncompromising come out of the commitee if it exists. If we are going to add concurrency, I'd like to see it done right. John -- John Meacham - ⑆repetae.net⑆john⑈

6998

Age (days ago)

7000

Last active (days ago)

List overview

Download

5 comments

6 participants

participants (6)

isaac jones
John Meacham
Malcolm Wallace
Manuel M T Chakravarty
Ross Paterson
Simon Marlow