[Haskell-cafe] Non-strict evaluation and concurrency (STM) : conflict?

Felipe Lessa felipe.lessa at gmail.com
Tue Sep 28 10:46:51 EDT 2010

On Tue, Sep 28, 2010 at 11:38 AM, Romain Demeyer
<romain.demeyer at gmail.com> wrote:
> Does it means that the value is computed by the "caller", based on the
> thunk, and not by the worker itself?

It is computed by the one who needs the value.  Your worker doesn't.
Note that the value is computed on 'print', which is *after* the
worker has returned the value.  So, it is the caller who evaluates,
but it does not evaluate while calling the worker.

> In this case, in this specific example, it would mean that this program does
> not exploit the parallelism at all (except using deepseq or seq).
> I understand the principles (lazy evaluation, thunk,...) , but I'm surprised
> that no work has been done to "solve" this problem (in the sense that it's
> not intuitive to write concurrent programs in this context).

It is not a problem, it is a feature.  It is our beloved lazy
evaluation applied to STM.

Alas, there isn't a single "solution".  You may want 'seq', 'deepseq'
or something between.  Your data may already be in WHNF or HNF, so
calling 'seq' or 'deepseq' always would decrease performance for no
gain on these cases.  And sometimes you really want the lazy
behaviour, for example, if you were using an infinite data structure.

It is only a problem when you are learning how to use concurrency or
parallelism in Haskell.  Just repeat to yourself that everything is
lazy and you'll get used to it =).



More information about the Haskell-Cafe mailing list