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