Use of evaluate in Control.Concurrent.MVar

[David Feuer]

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.
>
> Roman
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries