MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Edward Kmett]

On Thu, Nov 26, 2015 at 3:28 AM, Akio Takano <tkn.akio at gmail.com> wrote:
>
> This is true, but I think it's much better to avoid breaking people's
> code in the first place. Also, since the breakage can be silent, one
> will not always be able to make a fix promptly.
>

We're not talking about making this change until we can get some warnings
in place.

That said, in the presence of some existing combinators that have already
been generalized from Monad to Applicative you may want to ensure that
these definitions have been fixed already.

>
> > In situations where (<*>) is asymptotically more efficient than (>>=)
> then
> > the default definition in terms of (<*>) wins.
>
> You are right. I hadn't thought about this.
>
> >
> > Right now, if you run through hackage there are lots of places where (>>)
> > has been manually improved but the (*>) has not -- or vice versa. We have
> > two places where people should apply an optimization and many have only
> > realized that they should optimize one or the other.
> >
> > The key here is to encourage folks to actually define (*>) when it
> matters.
>
> I understand this, but perhaps there is a way to achieve this without
> slowing down existing code. How about introducing a new warning
> (enabled with -Wall) that is triggered when a type satisfies the
> following 3 conditions?
>
> 1. The type has a Monad instance and an Applicative instance declared
> in the same module, with the same set of constraints.
> 2. (*>) is not defined as (*>) = (>>). i.e. either it has a
> non-trivial definition or its definition is left out.
> 3. (>>) is not defined as (>>) = (*>). i.e. either it has a
> non-trivial definition or its definition is left out.
>
> This way, people can be warned when (*>) and (>>) can share an
> implementation but they don't.


This is pretty much what Herbert has been working on, except with the
definition biased in favor of (>>) = (*>) being expected, and the other
becoming a warning as that definition blows up when and if we later move
(>>) out of the class.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151126/450f57a7/attachment.html>