[Haskell-cafe] Why Kleisli composition is not in the Monad signature?
AUGER Cédric
sedrikov at gmail.com
Tue Oct 16 16:03:02 CEST 2012
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
> >
More information about the Haskell-Cafe
mailing list