@hackage mtl-evil-instances0.1

Instances for the mtl classes for all monad transformers.

  • Categories

    • License

      LicenseRef-PublicDomain

    • Maintainer

      shane@duairc.com

    • Versions

      • 0.1 Wed, 29 Feb 2012

    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!