Something I wanted to do for a long time and finally got around to.

Historical background: we used to take the ability to throw an error in a
computation for granted in any Monad, due to the mis-guided inclusion of the
'fail' method in the Monad class. This has been fixed several ghc versions
ago. To cope with that, I replaced calls to 'fail' with calls to 'throw'
(with manually crafted IOExceptions) when applying a patch fails. But using
the (pure) 'throw' is unclean; it is better to make the requirements for the
base monad explicit by using a MonadThrow constraint, which allows non-IO
base monads to use a pure implementation of 'throwM'.

1 patch for repository http://darcs.net/screened:

patch c2737fa99e15af26c36602ec445ffeb4a10db25d
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Sep 19 14:00:41 CEST 2021
  * require MonadThrow from the base apply monads

  This avoids having to throw from pure code when applying patches in a monad
  that is not based on IO. In Prim.FileUUID we now correctly handle all patch
  application errors as exceptions. In D.P.ApplyMonad, the FilePathMonad is
  now a StateT over a Pure monad with an instance MonadThrow that calls error;
  in the harness, the Fail monad is now a synonym for Either SomeException.

Attachments

• patch-preview.txt
• require-monadthrow-from-the-base-apply-monads.dpatch