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
