Instances for the mtl classes for all monad transformers.
|Latest on Hackage:||0.1|
This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow stackage.org to host generated Haddocks.
WARNING: THIS PACKAGE IS EVIL. DO NOT USE IT!
It is common when defining a monad transformer to define instances for that
transformer for each class in the
mtl library, to allow easy composition
with the existing standard monad transformers. However, doing this is very
tedious, and actually unnecessary, given that most of these instances across
different transformers are identical, and can actually be expressed purely
in terms of
MonadTransControl (from the
package) for the more complicated classes.
The reason this is not generally done is because it requires the
OverlappingInstances extension, which is generally considered evil.
However, it does actually work. If you define a monad transformer, and
MonadTransControl, and import
Control.Monad.Instances.Overlapping, your monad transformer will magically
have sensible instances for all the
mtl type classes. And if you don't
like one of the instances provided, you can always define your own instance,
which will override the "default" one provided by this package, because by
the rules for
OverlappingInstances, your instance is more "specific"
than the one exported by
The main disadvantage of this is that errors in code using
OverlappingInstances can result in some really strange error messages that
are not very helpful. The reason this is evil is because this places an
additional burden (of dealing with confusing error messages) not just on
those who use this package directly, but anybody who indirectly uses any
code that, somewhere down the line, imported
Control.Monad.Instances.Overlapping, due to the "viral" nature of
instances. Also, if another person were to make a package very similar to
this one, and somebody ended up importing both code that used this package,
and code that used the other package, than neither of them would work
anymore. This is the problem with orphan instances.
If you absolutely insist on using this code, you should probably define
manual instances for the
mtl classes the hard way as well, to avoid this
kind of breakage (thus defeating the purpose of this package). Of course,
realistically, this package is for everyone who wishes to ignore all such
advice and do bad things anyway (including myself). This is my gift to you!