Give MonadTrans a QuantifiedConstraints superclass

[Viktor Dukhovni]

On Thu, Jun 03, 2021 at 10:12:01AM +0900, 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.
> 
> 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!

+1.  Yes, as much as one might fondly remember C '89, Perl 4, Python 2,
Haskell 98, ...  the 90's are long over, and it is time to let go.

On Wed, Jun 02, 2021 at 06:05:20PM -0700, Edward Kmett wrote:

> > I feel like instead, MonadTrans should have a function
> >
> > (>>==) :: Monad m => t m a -> (a -> t m b) -> t m b
> 
> This strikes me as a strictly worse outcome. Now you get coherence laws
> relating (>>==) to a (>>=) that may or may not exist that you have to keep
> track of, but get nothing enforcing anything, can't delegate to code that
> builds off Monad, leading to random code duplication, and users are hoist
> on the horns of the dilemma of using (>>=) or (>>==) with
> different constraints in each circumstance.

+1.

-- 
    Viktor.