important news: refocusing discussion

[Simon Marlow]

On 24 March 2006 09:55, Ross Paterson wrote:

> Do you envisage Haskell' implementations that do not support
> concurrency? 

Clearly there will be some, the question is what status do they have.
It boils down to a choice between:

 (1) Haskell' does not include concurrency.  Concurrent programs 
     are not Haskell'.

 (2) Haskell' includes concurrency.  Concurrent programs are
     Haskell', but there are some compilers that do not implement
     all of Haskell'.

 (3) There are two variants of Haskell', Haskell' and
     Haskell'+Concurrency.  Compilers and programs choose which
     variant of the language they implement/are implemented in.

 (4) The same as (3), but the two variants are Haskell' and
     Haskell'-Concurrency  (where -Concurrency is a negative
     addendum, an addendum that subtracts from the standard).

I suspect that almost everyone agrees that (1) is not an option.  In
practical terms, there isn't much to choose between the others: from a
programmer's point of view, if they want to use concurrency they still
have to choose an implementation that supports it.

So I believe the issue is mainly one of perspective.  Until I wrote this
email I hadn't thought of (4) and my preference was for (2), but now I
quite like the idea of (4).  We would include concurrency in Haskell',
but provide a separate addendum that specifies how imlementations that
don't provide concurrency should behave.  One advantage of (4) over (3)
is that we can unambiguously claim that Haskell' has concurrencey.

This also lets us accommodate John Meacham's earlier point, that it
should be possible to write concurrency-safe libraries in a portable
way, and that means providing parts of Control.Concurrent even in the
absence of concurrency.  For example, MVars would be provided with an
implementation in terms of IORefs.

Cheers,
	Simon