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.

>
> 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.