Priorities

[Tomasz Zielonka]

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