Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Edward Kmett]

Sadly liftM vs. liftA actually retains a useful distinction, one is a
definition of fmap in terms of (>>=) and the other in terms of (<*>).

`ap` gives a default definition of (<*>) in terms of (>>=), but if someone
instead writes (<*>) = liftM2 id today, then erasing the distinction would
turn that into a circular definition, transforming obviously-correct
existant code silently into a _|_.

-Edward

On Thu, Sep 24, 2015 at 8:36 PM, Dan Burton <danburton.email at gmail.com>
wrote:

> What about the derived functions in Control.Monad, such as liftM? Shall we
> similarly relax their constraints to Applicative and consider them
> "legacy"? (Did this already happen when I wasn't looking?)
>
>
> On Thursday, September 24, 2015, John Wiegley <johnw at newartisans.com>
> wrote:
>
>> >>>>> Herbert Valerio Riedel <hvr at gnu.org> writes:
>>
>> > TLDR: To complete the AMP, turn `Monad(return)` method into a
>> >       top-level binding aliasing `Applicative(pure)`.
>>
>> Very much +1.
>>
>> John
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> --
> -- Dan Burton
>
> _______________________________________________
> 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/20150924/977b1a59/attachment.html>