Re: Give MonadTrans a QuantifiedConstraints superclass
George Wilson <[email protected]>
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <CABzzMazzPU2zhoLerxArGqBK74F49H50h1wAJYJehDD0F_JC3g@mail.gmail.com> |
+1 to the quantified constraint. It would be nice to be able to talk about monad transformer composition. Cheers, George On Thu, 3 Jun 2021 at 19:08, Edward Kmett <[email protected]> wrote: > > > > On Wed, Jun 2, 2021 at 11:07 PM Henning Thielemann <[email protected]> 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. > > -Edward > >> _______________________________________________ >> Libraries mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries