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⑈