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

16 Oct 2012

      Le Tue, 16 Oct 2012 07:35:34 +0530,
damodar kulkarni  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
wrote:
...
On Mon, Oct 15, 2012 at 11:33 AM, Jake McArthur
 wrote:
...
On Mon, Oct 15, 2012 at 7:59 AM, Ertugrul Söylemez 
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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe