On Wed, Jun 2, 2021 at 11:07 PM Henning Thielemann < lemming@henning-thielemann.de> 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries