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@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe