The goals of the concurrency standard?

[oleg at pobox.com]

Simon Marlow wrote:
> >	do
> >	r <- return (mersenne' 44)
> >	acquire'lock
> >	putStrLn "Great success"
> >	print r
> >	release'lock
> > One may think that the long computation occurs in the "r <- ..." line.
> > Alas, it may just as well occur in the "print r" line, when the digits
> > of the number are really required to print. So, we will be running a
> > long computation while holding a lock. This isn't much better than the
> > situation with the cooperative scheduling, is it?
>
> In cases where this happens, and it *does* happen, the programmer has to
> insert explicit seq or deepSeq.  It's not a huge problem, at least no
> worse than the need to use seq/deepSeq to control resource usage or
> exception leakage.  The code inside a lock/unlock sequence is usually
> quite short, and we can enumerate the free variables quite easily.

My main trouble is foundational. The very "need to use
seq/deepSeq" is quite disturbing: in the above example, we must use
those constructions (and so, deepSeq must be standardized, if we take
this route). Evaluation time (and divergence) is certainly an effect;
when composing with another effect such as locking, we must be able to
specify the exact sequence of those effects. Essentially, the need for
seq/deepSeq seems to tell that non-strict evaluation is an inadequate
computational model in the example at hand.

Incidentally, the need to manually insert deepSeq isn't that much
different from the need to insert safe points? In both cases, the
programmer must be aware how much of the computation has already been
done at (some) program points, and be able to control the amount of
computation done. Strictly speaking, none of that is possible under
non-strict evaluation.

> Fortunately STM helps a lot here, too. 
Yes, it does. The previous message pointed out that the STM model
seems to be similar to the one used in Erlang. With STM, we can keep
lazy evaluation and the programmer does not need to think of
seq/deepSeq, etc. But there is a price to pay: we can't use FFI while
in the STM monad, we can't use IORefs and we can't use MVars. Right?
So, if the STM model is to become the default one (which would be a
great thing), FFI and the whole IO will have to be re-designed, and
IORefs and MVars removed from the language.