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

[John Meacham]

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⑈