[Haskell-cafe] Why Kleisli composition is not in the Monad signature?

[David Thomas]

I think the version below (with a Functor or Applicative superclass)
is clearly the right answer if we were putting the prelude together
from a clean slate.  You can implement whichever is easiest for the
particular monad, use whichever is most appropriate to the context
(and add optimized versions if you prove to need them).  I see no
advantage in any other specific proposal, except the enormous
advantage held by the status quo that it is already written, already
documented, already distributed, and already coded to.

Regarding mathematical "purity" of the solutions, "this is in every
way isomorphic to a monad, but we aren't calling it a monad because we
are describing it a little differently than the most common way to
describe a monad in category theory" strikes me as *less*
mathematically grounded than "we are calling this a monad because it
is in every way isomorphic to a monad."

On Tue, Oct 16, 2012 at 7:03 AM, AUGER Cédric <sedrikov at gmail.com> wrote:
>
> So I think that an implicit question was why wouldn't we have:
>
> class Monad m where
>   return :: a -> m a
>   kleisli :: (a -> m b) -> (b -> m c) -> (a -> m c)
>   bind = \ x f -> ((const x) >=> f) ()
>   join = id>=>id :: (m (m a) -> m a)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe