On Fri, Feb 03, 2006 at 08:40:27AM -0000, Simon Peyton-Jones wrote:
| Some experts (like Hans Boehm) argue, that concurrency can't be added to | the language as a library. | http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf | | This is true for many imperative programming languages. Haskell seems | to be an exception: | http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December/00 9417.html
The interface can be a library, but (a) what libraries are available is part of the language definition and (b) it's hard to build a good implementation without runtime support. And the nature of the runtime support depends on what the library interface is.
I forgot about runtime support. My point is that you we able to introduce a library/runtime support without changing the semantics of the language, and it works well.
So a programmer asks "can I write my Haskell' program using concurrency?". To answer that question, concurrency needs to be specified as part of Haskell', just as (say) Integer and its operations do. [Of course, we can choose not to; and then Haskell' programs will be single-threaded.]
Yes, you are right. I was not entirely serious in my argumentation ;-) Even if concurrency is part of Haskell', it should still be clear that it doesn't affect the definition of non-concurrent Haskell' subset at all (is that true?). For example, all pure functions will be entirely thread-safe. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland