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.