Re: Give MonadTrans a QuantifiedConstraints superclass
Viktor Dukhovni <[email protected]>
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <[email protected]> |
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.
_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries