Give MonadTrans a QuantifiedConstraints superclass

[Fumiaki Kinoshita]

+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.

Adding `(>>==) :: Monad m => t m a -> (a -> t m b) -> t m b` seems even
worse; it will break every single instance of MonadTrans in the ecosystem!


2021年6月3日(木) 9:45 Zemyla <zemyla at gmail.com>:

> return is lift . return. Upon reflection, I believe (though may be
> mistaken) that every MonadTrans is also an instance of a hypothetical
> FunctorTrans class, only requiring a Functor constraint to be a
> Functor itself; however, ApplicativeTrans doesn't work because StateT
> among others requires a Monad constraint to be an Applicative.
>
> On Wed, Jun 2, 2021 at 6:41 PM Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> >
> > That sounds like a nice idea.  Which laws would we require for it?  The
> usual monad laws require a pure too right? Along with fmap?
> >
> > Does this necessitate the existence of applicative trans?
> >
> > On Wed, Jun 2, 2021 at 12:06 PM Zemyla <zemyla at gmail.com> wrote:
> >>
> >> I feel like instead, MonadTrans should have a function
> >>
> >> (>>==) :: Monad m => t m a -> (a -> t m b) -> t m b
> >>
> >> That way, it can prove it's a Monad while still staying Haskell 98.
> >>
> >> On Wed, Jun 2, 2021, 10:51 Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
> >>>
> >>> On Wed, Jun 02, 2021 at 07:27:28AM +0200, Henning Thielemann wrote:
> >>>
> >>> > So far, 'transformers' is mostly Haskell 98. This is why I prefer it
> >>> > to 'mtl'. Wouldn't it be enough to add this extension to 'mtl'? I see
> >>> > that 'mtl' re-uses the MonadTrans class from 'transformers' but maybe
> >>> > it should define its own class with the quantified constraints then.
> >>>
> >>> I don't think that having two incompatible MonadTrans classes would
> >>> constitute progress.  Older versions of the transformers library (which
> >>> is by now quite stable) will continue to be available, for anyone who
> >>> wants to use a Haskell '98 (ish?) version.
> >>>
> >>> [ FWIW, I don't know what you mean by "is mostly Haskell '98", I'd
> >>>   expect that to be a strict binary choice: is or isn't. ]
> >>>
> >>> --
> >>>     Viktor.
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210603/317e9965/attachment.html>