Patch 2226 require MonadThrow from the base apply monads

Title require MonadThrow from the base apply monads
Superseder Nosy List bf
Related Issues
Status needs-review Assigned To

Created on 2021-11-20.11:30:25 by bf, last changed 2021-11-20.11:31:19 by bf.

File name Status Uploaded Type Edit Remove
patch-preview.txt bf, 2021-11-20.11:30:24 text/x-darcs-patch
require-monadthrow-from-the-base-apply-monads.dpatch bf, 2021-11-20.11:30:24 application/x-darcs-patch
See mailing list archives for discussion on individual patches.
msg22931 (view) Author: bf Date: 2021-11-20.11:30:24
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.
Date User Action Args
2021-11-20 11:30:25bfcreate
2021-11-20 11:31:19bfsetstatus: needs-screening -> needs-review