Give MonadTrans a QuantifiedConstraints superclass

[Carter Schonwald]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210602/d510d344/attachment.html>