Give MonadTrans a QuantifiedConstraints superclass

Edward Kmett ekmett at
Thu Jun 3 09:06:35 UTC 2021

On Wed, Jun 2, 2021 at 11:07 PM Henning Thielemann <
lemming at> wrote:

> On Thu, 3 Jun 2021, Fumiaki Kinoshita wrote:
> > +1 to the original proposal of using QuantifiedConstraints.
> >
> > There is no need to stick to the standard from 23 years ago, and having
> > two different classes is only likely to bring confusion and extra work
> > for library maintainers.
> But why do we have the separation between 'transformers' and 'mtl' then?

We have it though a combination of intent and historical accident.

Originally there was just `mtl`-1. Then `transformers` + (`monads-fd` |
`monads-tf`) came along with a couple of also-ran packages like
Galois' `monadLib`. The ecosystem splintered badly and nobody could work
with anybody in a different splinter. To merge the `mtl` portion of the
ecosystem with the monads-fd ecosystem, we renamed the latter to `mtl`-2,
and the `monads-tf` corner of the ecosystem silently died because nobody
was using it and it conflicted in the module names with things that people
did use.

`transformers` was then sort of retroactively justified for two reasons,
one to provide a "simple" core, then-Haskell98ish package like you suggest.

`transformers` has supported things like PolyKinds for a long time, leans
on StandaloneDeriving, etc. so it isn't exactly the first chink in that
first justification's armor.

Another justification was to supply a common base for experimentation on
things like `monads-fd` and `monads-tf` and all the gajillion
effect-system-alikes that have been built on top that do things like
replace the `MonadFoo` classes with ones that use type families or tags or
remove the functional dependencies.

The latter mission remains intact.


> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list