name: mtl-evil-instances
version: 0.1
synopsis: Instances for the mtl classes for all monad transformers.
license: PublicDomain
license-file: LICENSE
author: Shane O'Brien
maintainer: shane@duairc.com
stability: Experimental
category: Control
cabal-version: >= 1.6
build-type: Simple
description:
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 @MonadTrans@, or @MonadTransControl@ (from the @monad-control@
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
instances for @MonadTrans@ 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 "Control.Monad.Instances.Overlapping".
.
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!
extra-source-files:
CONTRIBUTORS
Library
hs-source-dirs:
src
exposed-modules:
Control.Monad.Instances.Evil
build-depends:
base > 4 && < 5,
mtl > 2 && < 2.1,
monad-control > 0.3 && < 0.4,
transformers > 0.2 && < 0.3,
transformers-base > 0.1 && < 0.5