Use of evaluate in Control.Concurrent.MVar

David Feuer david.feuer at
Mon Oct 12 19:23:07 UTC 2020

Yes, I generally understand that; I just don't *think* it applies
here. The issue with `seq` tends to be that strictness information can
propagate "back in time", or forcing can be delayed, etc. I just don't
immediately see that as an issue in this *particular* spot. That said,
I imagine that in many cases the compiler will see that the pair is
surely produced, in which case the `evaluate` will go away.

On Mon, Oct 12, 2020 at 2:20 PM Roman Cheplyaka <roma at> wrote:
> Hi David,
> On 12/10/2020 21.01, David Feuer wrote:
> > Couldn't we just do this?
> >
> > modifyMVar m io =
> >   mask $ \restore -> do
> >     a      <- takeMVar m
> >     (a',b) <- restore (io a >>= (pure $!)) `onException` putMVar m a
> >     putMVar m a'
> >     return b
> No — the haddocks for 'evaluate' in Control.Exception explain the difference between the two. In particular,
> > The rule of thumb is to use evaluate to force or handle exceptions in lazy values. If, on the other hand, you are forcing a lazy value for efficiency reasons only and do not care about exceptions, you may use return $! x.
> If you want to know why, I think you can find some old bugs in the ghc bug tracker that resulted from an incorrect usage of return $! ... where evaluate was warranted.
> Roman
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list