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

[AUGER Cédric]

Le Tue, 16 Oct 2012 07:35:34 +0530,
damodar kulkarni <kdamodar2000 at gmail.com> a écrit :

> @Jake
> 
> In my opinion, this is not as nice as the do-notation version, but at
> > least it's compositional:
> 
> 
> That's an important point you have made, as Haskellers value code
> composition so much.
> If code composition is the "holy grail", why not encourage the monadic
> code, too, to be compositional? Nicety can wait; some syntax sugar
> might take care of it.
> 
> And as you have pointed out, arrows make a superior choice in this
> regard, but they are rather newer to monads.
> 
> @ AUGER Cédric
> 
>  It would be rather awful to expand each of your Kleisli arrows with
> >
> "const" as you said.
> >
> 
> The const is required in this example because we are dealing with
> getLine (as getLine can return different strings at different times
> without taking any argument). Again, some syntactic sugar would have
> taken care of this "const" thing.
> 
> Correct me if I am wrong.

We were not dealing with getLine in particular. The point was about
knowing if >>= could be defined in terms of >=>. The const is necessary
for the general case. 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)

(Sorry, I do not remember the correct Haskell syntax, I am a beginner,
but I do not have touched the language for some time…)

That is "bind" would have a default construction (like "join" has got
its one now).

The definition of "join" would become rather nice this way ^^

Not redefining the "join" and "bind" function would lead to expand them
with "\ x f -> (const x) >=> f" and "id>=>id", that is what I meant, and
found it awful for "bind". Of course I do not say that Kleisli is a bad
idea. I even think it is better to use it when you want composition, or
you want to do the initial given example (readString >=> putString, or
something like that, I do not really remember). But I do not think
defining Monads from Kleisli (or T-algebras, for the other adjunction
construction) would be very nice. On the other hand, I guess that the
class Monad could contain the definition of Kleisli arrows. But as we
have instances ArrowApply a => Monad (ArrowMonad a) and Monad m =>
Arrow (Kleisli m), I do not think we lack some functionnality.

> 
> and thanks for responses.
> 
> Damodar
> 
> On Mon, Oct 15, 2012 at 9:09 PM, Jake McArthur
> <jake.mcarthur at gmail.com>wrote:
> 
> > On Mon, Oct 15, 2012 at 11:33 AM, Jake McArthur
> > <jake.mcarthur at gmail.com> wrote:
> > > On Mon, Oct 15, 2012 at 7:59 AM, Ertugrul Söylemez <es at ertes.de>
> > > wrote:
> > >> Try to express
> > >>
> > >>     do x <- getLine
> > >>        y <- getLine
> > >>        print (x, y)
> > >>
> > >> using only Kleisli composition (without cheating).
> >
> > My previous answer didn't do the Kleisli style much justice. It
> > could look a bit nicer with more Arrow-style combinators:
> >
> >     f &=& g = runKleisli $ Kleisli f &&& Kleisli g
> >
> >     print <=< const getLine &=& const getLine $ ()
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >