The goals of the concurrency standard?

[John Meacham]

Fortunatly, I don't expect these issues to be much of a problem in
practice. (though, they certainly are real issues)

the vast majority of programs, haskell ones included, are either
interactive or batch. an interactive program spends most of its time
waiting for user input or external events, responding, and in general
using very little CPU, this is the sort of app threads are ideal for,
text editors, chat clients, window managers, etc... batch programs are
things like compilers or meresenne prime calcalculators, that tend to
accept input, run for a while, and produce output. however, these types
of programs rarely need concurrency.

not that all programs fall into those categories, one can write their
GUI enabled meresenne prime calculator, and then they will have to worry
about such things. but at least with the standard they can now say 'this
requires the OS threading option' rather than 'this requires GHC'.

in any case, the situation you describe has been the case in GHC for a
long time and has not seemed to hurt the use of concurrency for writing
a lot of useful apps.

However, I am also of the mind that preemtiveness alone doesn't buy
enough to make the runtime cost of locking worth it which is why I plan
for jhc to be fully cooperative or fully OS threaded with no middle
ground. but the situation is different in compilers such as nhc, where
preemptiveness can be added relatively easily due to its run-time design
and absolute speed was never a goal. In any case, the standard should
admit a range of implementations.

though, your erlang example reminds me of a truely horrid hack I did
with jhc once when experimenting with concurrency models, link two
instances of haskell programs together and have them communicate via the
FFI while running in different OS threads :)

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈