diff --git a/README.md b/README.md --- a/README.md +++ b/README.md @@ -27,32 +27,32 @@ Now, if one called `foo` in a `Maybe monad`: ->>> foo :: Maybe Int ->>> Nothing + > foo :: Maybe Int + > Nothing the failure is then conveyed by returning `Nothing` as per definition of the `Maybe` monad. Now in the case of the `Either SomeException` monad: ->>> foo :: Either SomeException Int ->>> Left NotImplemented + > foo :: Either SomeException Int + > Left NotImplemented but what if we are working in the `IO` monad? ->>> foo :: IO Int ->>> * * * Exception: NotImplemented + > foo :: IO Int + > * * * Exception: NotImplemented In this case, the failure can only be conveyed by throwing an IO exception. Now, the point where `Failable` diverges from say `MonadThrow` for example is when it comes to monad transformers. For example: ->>> runMaybeT foo :: IO (Maybe Int) + > runMaybeT foo :: IO (Maybe Int) Would throw an `Exception: NotImplemented` if it was implemented in a `MonadThrow` context. Since the reason d'etre for the runMaybeT is to provide the underlying monad (transformer) with `Maybe` like behaviour, i.e. have `Nothing` be returned in case of aborting the `Maybe` pipeline so to speak, then throwing an exception defeats IMHO the purpose of using `MaybeT` in the first place. So, in the case of `Failable`: ->>> runMaybeT foo :: IO (Maybe Int) ->>> Nothing + > runMaybeT foo :: IO (Maybe Int) + > Nothing And the same thing applies to `runExceptT` etc. diff --git a/failable.cabal b/failable.cabal --- a/failable.cabal +++ b/failable.cabal @@ -4,10 +4,10 @@ -- -- see: https://github.com/sol/hpack -- --- hash: c71b774e75efdc6c11a1cd835a896e69b5b91d60a4e0a8fb6428c65ca6f5b0a1 +-- hash: ff6aece6bf22bb1b3620af9875c66efc4beb3470e1cffbfa8cbff2b06b5a0b8e name: failable -version: 0.1.0.0 +version: 0.1.0.1 synopsis: A 'Failable' error monad class to unify failure across monads that can fail description: Please see the README on GitHub at category: control, exceptions, monad