<div dir="ltr"><div>+1 to the original proposal of using QuantifiedConstraints.</div><div><br></div><div>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.</div><div><br></div><div>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!<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年6月3日(木) 9:45 Zemyla <<a href="mailto:zemyla@gmail.com">zemyla@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">return is lift . return. Upon reflection, I believe (though may be<br>
mistaken) that every MonadTrans is also an instance of a hypothetical<br>
FunctorTrans class, only requiring a Functor constraint to be a<br>
Functor itself; however, ApplicativeTrans doesn't work because StateT<br>
among others requires a Monad constraint to be an Applicative.<br>
<br>
On Wed, Jun 2, 2021 at 6:41 PM Carter Schonwald<br>
<<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
><br>
> 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?<br>
><br>
> Does this necessitate the existence of applicative trans?<br>
><br>
> On Wed, Jun 2, 2021 at 12:06 PM Zemyla <<a href="mailto:zemyla@gmail.com" target="_blank">zemyla@gmail.com</a>> wrote:<br>
>><br>
>> I feel like instead, MonadTrans should have a function<br>
>><br>
>> (>>==) :: Monad m => t m a -> (a -> t m b) -> t m b<br>
>><br>
>> That way, it can prove it's a Monad while still staying Haskell 98.<br>
>><br>
>> On Wed, Jun 2, 2021, 10:51 Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>> wrote:<br>
>>><br>
>>> On Wed, Jun 02, 2021 at 07:27:28AM +0200, Henning Thielemann wrote:<br>
>>><br>
>>> > So far, 'transformers' is mostly Haskell 98. This is why I prefer it<br>
>>> > to 'mtl'. Wouldn't it be enough to add this extension to 'mtl'? I see<br>
>>> > that 'mtl' re-uses the MonadTrans class from 'transformers' but maybe<br>
>>> > it should define its own class with the quantified constraints then.<br>
>>><br>
>>> I don't think that having two incompatible MonadTrans classes would<br>
>>> constitute progress.  Older versions of the transformers library (which<br>
>>> is by now quite stable) will continue to be available, for anyone who<br>
>>> wants to use a Haskell '98 (ish?) version.<br>
>>><br>
>>> [ FWIW, I don't know what you mean by "is mostly Haskell '98", I'd<br>
>>>   expect that to be a strict binary choice: is or isn't. ]<br>
>>><br>
>>> --<br>
>>>     Viktor.<br>
>>> _______________________________________________<br>
>>> Libraries mailing list<br>
>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
>><br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>