Use of evaluate in Control.Concurrent.MVar
david.feuer at gmail.com
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 ro-che.info> 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.
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries