GitLab

Michael Snoyman authored Feb 11, 2018 and Ryan Scott committed Feb 11, 2018

* More consistent generalBracket implementations

The behavior is identical to before, but since I'm about to use these
instances in the docs, I wanted to raise less confusing questions to
readers about implementation.

* Docs explaining generalBracket implementation

Michael Snoyman authored Jan 28, 2018 and Ryan Scott committed Jan 28, 2018

* Demonstrate broken ExceptT instance for MonadMask

* Simplify generalBracket so it works for ExceptT

The previous type signature was in fact invalid, as it did not allow for
a valid instance for ExceptT (et al). In particular, in the case of a
non-exceptional Left result, neither the release nor cleanup functions
could be used, since:

* No result value was available for release
* No SomeException value was available for cleanup

It appears that this less pleasing version of generalBracket is the only
one that works for all the types we care about.

Furthermore: once we accept this, we are now forced to perform some
discarding of updated state and Monoid written values in the StateT,
WriterT, and RWST instances. This seems inherent to making things
compatible with ExceptT.

An alternative to this is to simply remove the ExceptT and ErrorT
instances, but that's contrary to what many users want it seems.

* Doc cleanups @RyanGIScott's review

Andrés Sicard-Ramírez authored Jan 15, 2018 and Ryan Scott committed Jan 15, 2018

Fix compilation with GHC 8.4.1. Tested with GHC 8.4.1-alpha1.

Add generalBracket to MonadMask

I just realized that the function could be more general, and thereby
more explicit in its intent, but allowing the non-exceptional release
function to return a different type than the inner function.

For motivation, see:
https://www.fpcomplete.com/blog/2017/02/monadmask-vs-monadbracket

Michael Snoyman authored Jul 20, 2016 and Ryan Scott committed Jul 20, 2016

Came up in a discussion with @bitonic. There's no downside I can see to
the MonadCatch instance. However, the MonadMask instance is a little bit
more controversial, in that it's not actually doing any masking.
However, it's impossible to know that it's not masking the async
exceptions since there are no side-effects from the Either monad.

Of course, by using unsafePerformIO, we could observe the difference,
but I think that's a valid trade-off.

One final argument against MonadMask for Either: it's probably not
terribly useful.

Bump dependency on transformers-compat to < 0.6

fix documentation typo

Bump QuickCheck upper bound

Bump template-haskell version bound for GHC 8

Tests pass against the new version of TH, we can probably just edit the .cabal file on hackage rather than creating a new release.

Transformers5

canonical-AMP-warning avoidance