<p>In monads, Kleisli composition has the type</p>
<pre><code>infix oK: ('b -&gt; 'c monad) -&gt; ('a -&gt; 'b monad) -&gt; ('a -&gt; 'c monad)
</code></pre>
<p>and it satisfies the nice algebraic associativity law</p>
<pre><code>(f oK g) oK h = f oK (g oK h)
</code></pre>
<p>But in Haskell rather <code>bind</code> is used:</p>
<pre><code>bind: ('a monad) -&gt; ('a -&gt; 'b monad) -&gt; ('b monad)
</code></pre>
<p>whose &quot;associativity&quot; law in not the classic algebraic one:</p>
<pre><code>bind m (λa. bind  (k a) (λb. h b)) = bind (bind m (λa. k a)) (λb. h b)
</code></pre>
<p>What reasoning led to this choice of favoring <code>bind</code> over Kleisli composition?</p>

<haskell><monads><history>
Why does Haskell use the bind operation instead of Kleisli composition?
CC BY-SA 4.0
2024-03-21T02:03:19.400Z
I don't understand... how can it be said that it's the language making the choice, rather than the programmers, given that both operations are apparently supported by the language syntax?
Karl Knechtel
CC BY-SA 4.0
2024-03-21T02:39:24.377Z
@KarlKnechtel In the Haskell standard library, bind is taken as the fundamental operation and Kleisli composition is implemented in terms of bind. It's possible to do it the other way around, this is just the choice Haskell has made. I think the question is about this choice.
David Young
CC BY-SA 4.0
2024-03-21T13:21:10.910Z
@DavidYoung I came to monads from an algebraic point of view and there Kleisli composition is actually the operation in the monoid that is induced by the monadic structure.
Gergely
CC BY-SA 4.0
2023-08-07T11:13:54.833Z
Also, who's "they"? Kleisli composition is available in Haskell as `>=>`, it's just not used quite as much as other combinators. I also don't know what "practical" rationale you're expecting. You can always rewrite `a >>= b ≡ (const a >=> b) ()` and `a >=> b ≡ (>>= b) . a`. The closest thing to a 'reason' is that monads were introduced originally to represent `IO`, and you'd typically want to end on `IO ()` not `a -> IO ()`, other than that slight convenience the choice is completely arbitrary
Cubic
CC BY-SA 4.0
2023-08-07T11:19:30.187Z
Associativity being a little easier to express with one form certainly isn't really a selling point for preferring that form in a programming language.
Cubic
CC BY-SA 4.0
2023-08-08T20:50:38.040Z
@Cubic: If one's language is point-free, then associativity directly leads to shorter code. This question was useful food for thought.
Corbin
CC BY-SA 4.0
2023-08-09T16:30:27.373Z
@Cubic - I've not written a huge amount of Haskell code (a handful of parsers and interpreters when I was playing with parser combinators a while back probably represents most of it) but I have found Kleisli composition very useful at times, enough that I've wondered why it doesn't feature in tutorials more often.  This also applies to some of the Arrow combinators, which are particularly useful due to the fact that there's a default instance of Arrow for functions, so you can use them anywhere.
occipita
CC BY-SA 4.0
2023-08-10T17:48:45.117Z
@Corbin I give the rewrite rules above. The rewrite only adds a constant length, no matter how long your expression is. Also, `>>=` is still just as associative as `>=>`, it's just not as easy to see.
Cubic
<p>Two examples:</p>
<ol>
<li><p>Consider do notation:</p>
<pre><code>do
  a &lt;- f x
  b &lt;- g a
  h b
</code></pre>
<p>This desugars to:</p>
<pre><code>f x &gt;&gt;= (\a -&gt; g a &gt;&gt;= (\b -&gt; h b))
</code></pre>
<p>Quite simple to understand, and a straightforward transformation. Now, with Kleisli composition, this is much harder to &quot;nicely&quot; implement.</p>
</li>
<li><p>Consider <code>bind</code> itself:</p>
<pre><code>f x 
&gt;&gt;= g
&gt;&gt;= h
</code></pre>
<p>This reads nicely in a programming language, whereas the equivalent with kleisli composition does not. (I personally can't even do kleisli composition in my head, whereas bind is easy). Remember, not everything is about properties like nice associativity or similar - readability is paramount.</p>
</li>
</ol>

CC BY-SA 4.0
2023-08-08T01:01:36.253Z
2023-08-08T01:35:07.197Z
2023-08-08T01:35:07.197Z
blueberry
CC BY-SA 4.0
2023-08-08T01:27:49.517Z
Please don’t delete your answer! It has useful examples, and I linked to it from mine, so if you deleted it, I’d have to incorporate them into my answer, anyway. :)
Alexis King
<p>All the above are neat answers. Just to add to the understanding of the importance of bind associativity and especially blueberry's answer, this article helped me understanding why bind is important from a programming language design point of view:</p>
<p><a href="https://wiki.haskell.org/Monad_laws" rel="nofollow noreferrer">https://wiki.haskell.org/Monad_laws</a></p>
<p>So bind is an implementation of a nice syntactic sugar, the do notation, which is intuitive for programmers.</p>
<p>Forgive me being an algebraist.</p>

CC BY-SA 4.0
2024-03-14T12:14:23.410Z
2024-03-14T12:14:23.410Z
Gergely
CC BY-SA 4.0
2024-03-14T13:35:05.057Z
As a trigonometrist myself, all your sins are forgiven.
kaya3
<p>The original reason monads were introduced in Haskell was to implement I/O. <a href="https://langdev.stackexchange.com/a/2518">This answer of mine</a> discusses many of the details of that usage, including the way things are implemented internally. Therefore, to understand the particular choice of methods included in the <code>Monad</code> typeclass, it’s helpful to focus on <code>IO</code> itself.</p>
<p>I/O involves sequencing a series of <em>actions</em> together. The goal is to essentially embed an effectful, imperative language into a pure, lazy, functional one. Each action to be sequenced is not something we think of as a function, but something we think of as an expression returning a value. This can be seen most obviously in <code>do</code> notation, which allows monadic programming to be performed in terms of statements that sequence these monadic values. <a href="https://langdev.stackexchange.com/a/2678">blueberry’s answer</a> already discusses how <code>&gt;&gt;=</code> naturally maps to <code>do</code> notation.</p>
<p>This is the main reason. But there are a few other factors as well:</p>
<ol>
<li><p>Bind and Kleisli composition are trivially expressible in terms of each other, and Haskell provides Kleisli composition in its standard library <a href="https://hackage.haskell.org/package/base-4.18.0.0/docs/Control-Monad.html#v:-62--61--62-" rel="noreferrer">under the names <code>&gt;=&gt;</code> and <code>&lt;=&lt;</code></a>.</p>
</li>
<li><p>Arguably, <code>join</code> would be a better choice than either <code>&gt;&gt;=</code> or <code>&gt;=&gt;</code>, as <code>Monad</code> has a <code>Functor</code> superclass, so a minimal specification would define <code>join</code> rather than <code>&gt;&gt;=</code> (as a definition of <code>&gt;&gt;=</code> essentially duplicates the definition of <code>fmap</code>). However, in practice, there are two reasons to prefer <code>&gt;&gt;=</code>:</p>
<ul>
<li><p>For many <code>Monad</code> implementations, specification in terms of <code>pure</code> and <code>&gt;&gt;=</code> is clearer than specification in terms of <code>pure</code>, <code>fmap</code>, and <code>join</code>. For that reason, many instances define <code>fmap</code> (and <code>&lt;*&gt;</code>, if we also consider <code>Applicative</code>) in terms of <code>&gt;&gt;=</code> rather than the other way around.</p>
</li>
<li><p>In theory, it ought to be possible to make <code>join</code> a method of <code>Monad</code> and allow users to specify whichever method they prefer, and in fact this used to be the case! However, the nested use of the monadic type in the argument to <code>join</code> prevents GHC’s <a href="https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/newtype_deriving.html" rel="noreferrer">automatic newtype deriving mechanism</a> from working with the class. In theory, this should be possible to fix using some relatively recent extensions to the type system, see <a href="https://ryanglscott.github.io/2018/03/04/how-quantifiedconstraints-can-let-us-put-join-back-in-monad/" rel="noreferrer">this blog post</a> for the details, but it’s such a minor thing that nobody has cared enough to do the necessary work.</p>
</li>
</ul>
</li>
<li><p>Since <code>&gt;=&gt;</code> always uses <code>-&gt;</code> as the underlying arrow, <code>&gt;&gt;=</code> is necessarily closer to what monads operationally do than <code>&gt;=&gt;</code> is. If composition is <a href="https://langdev.stackexchange.com/a/2372">generalized to an arbitrary arrow</a>, this may no longer be the case, as the “function-like thing” may be a user-defined type, and its members may themselves be primitive. However, as long as we’re known to be working with <code>-&gt;</code>, it can be slightly more efficient to use <code>&gt;&gt;=</code> as the method, since it will be packed in the dictionary used to implement unspecialized polymorphic functions with a <code>Monad</code> constraint.</p>
</li>
</ol>

CC BY-SA 4.0
2023-08-08T01:22:25.700Z
2023-08-08T01:29:14.777Z
2023-08-08T01:29:14.777Z
Alexis King
CC BY-SA 4.0
2023-08-08T01:26:23.350Z
+1 - this is a more thorough answer then mine.
blueberry
# Why does Haskell use the bind operation instead of Kleisli composition?
Posted by: username_0 on 2023-08-07
In monads, Kleisli composition has the type
infix oK: ('b -> 'c monad) -> ('a -> 'b monad) -> ('a -> 'c monad)

and it satisfies the nice algebraic associativity law
(f oK g) oK h = f oK (g oK h)

But in Haskell rather bind is used:
bind: ('a monad) -> ('a -> 'b monad) -> ('b monad)

whose "associativity" law in not the classic algebraic one:
bind m (λa. bind  (k a) (λb. h b)) = bind (bind m (λa. k a)) (λb. h b)

What reasoning led to this choice of favoring bind over Kleisli composition?
**Tags:** haskell monads history
> **Comments:**
> **username_3**: Also, who's "they"? Kleisli composition is available in Haskell as `>=>`, it's just not used quite as much as other combinators. I also don't know what "practical" rationale you're expecting. You can always rewrite `a >>= b ≡ (const a >=> b) ()` and `a >=> b ≡ (>>= b) . a`. The closest thing to a 'reason' is that monads were introduced originally to represent `IO`, and you'd typically want to end on `IO ()` not `a -> IO ()`, other than that slight convenience the choice is completely arbitrary  
> **username_3**: Associativity being a little easier to express with one form certainly isn't really a selling point for preferring that form in a programming language.  
> **username_4**: @Cubic: If one's language is point-free, then associativity directly leads to shorter code. This question was useful food for thought.  
> **username_5**: @Cubic - I've not written a huge amount of Haskell code (a handful of parsers and interpreters when I was playing with parser combinators a while back probably represents most of it) but I have found Kleisli composition very useful at times, enough that I've wondered why it doesn't feature in tutorials more often.  This also applies to some of the Arrow combinators, which are particularly useful due to the fact that there's a default instance of Arrow for functions, so you can use them anywhere.  
> **username_3**: @Corbin I give the rewrite rules above. The rewrite only adds a constant length, no matter how long your expression is. Also, `>>=` is still just as associative as `>=>`, it's just not as easy to see.  
> **username_1**: I don't understand... how can it be said that it's the language making the choice, rather than the programmers, given that both operations are apparently supported by the language syntax?  
> **username_2**: @KarlKnechtel In the Haskell standard library, bind is taken as the fundamental operation and Kleisli composition is implemented in terms of bind. It's possible to do it the other way around, this is just the choice Haskell has made. I think the question is about this choice.  
> **username_0**: @DavidYoung I came to monads from an algebraic point of view and there Kleisli composition is actually the operation in the monoid that is induced by the monadic structure.  
---
## 3 answers
### Answer by username_7 on 2023-08-08. Score: 27 | Accepted answer
The original reason monads were introduced in Haskell was to implement I/O. [This answer of mine](https://langdev.stackexchange.com/a/2518) discusses many of the details of that usage, including the way things are implemented internally. Therefore, to understand the particular choice of methods included in the `Monad` typeclass, it’s helpful to focus on `IO` itself.

I/O involves sequencing a series of *actions* together. The goal is to essentially embed an effectful, imperative language into a pure, lazy, functional one. Each action to be sequenced is not something we think of as a function, but something we think of as an expression returning a value. This can be seen most obviously in `do` notation, which allows monadic programming to be performed in terms of statements that sequence these monadic values. [blueberry’s answer](https://langdev.stackexchange.com/a/2678) already discusses how `>>=` naturally maps to `do` notation.

This is the main reason. But there are a few other factors as well:

1. Bind and Kleisli composition are trivially expressible in terms of each other, and Haskell provides Kleisli composition in its standard library [under the names `>=>` and `<=<`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Control-Monad.html#v:-62--61--62-).
2. Arguably, `join` would be a better choice than either `>>=` or `>=>`, as `Monad` has a `Functor` superclass, so a minimal specification would define `join` rather than `>>=` (as a definition of `>>=` essentially duplicates the definition of `fmap`). However, in practice, there are two reasons to prefer `>>=`:

   * For many `Monad` implementations, specification in terms of `pure` and `>>=` is clearer than specification in terms of `pure`, `fmap`, and `join`. For that reason, many instances define `fmap` (and `<*>`, if we also consider `Applicative`) in terms of `>>=` rather than the other way around.
   * In theory, it ought to be possible to make `join` a method of `Monad` and allow users to specify whichever method they prefer, and in fact this used to be the case! However, the nested use of the monadic type in the argument to `join` prevents GHC’s [automatic newtype deriving mechanism](https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/newtype_deriving.html) from working with the class. In theory, this should be possible to fix using some relatively recent extensions to the type system, see [this blog post](https://ryanglscott.github.io/2018/03/04/how-quantifiedconstraints-can-let-us-put-join-back-in-monad/) for the details, but it’s such a minor thing that nobody has cared enough to do the necessary work.
3. Since `>=>` always uses `->` as the underlying arrow, `>>=` is necessarily closer to what monads operationally do than `>=>` is. If composition is [generalized to an arbitrary arrow](https://langdev.stackexchange.com/a/2372), this may no longer be the case, as the “function-like thing” may be a user-defined type, and its members may themselves be primitive. However, as long as we’re known to be working with `->`, it can be slightly more efficient to use `>>=` as the method, since it will be packed in the dictionary used to implement unspecialized polymorphic functions with a `Monad` constraint.
> **Comments:**
> **username_6** (2023-08-08): +1 - this is a more thorough answer then mine.  
---
### Answer by username_6 on 2023-08-08. Score: 14
Two examples:

Consider do notation:
do
  a <- f x
  b <- g a
  h b

This desugars to:
f x >>= (\a -> g a >>= (\b -> h b))

Quite simple to understand, and a straightforward transformation. Now, with Kleisli composition, this is much harder to "nicely" implement.

Consider bind itself:
f x 
>>= g
>>= h

This reads nicely in a programming language, whereas the equivalent with kleisli composition does not. (I personally can't even do kleisli composition in my head, whereas bind is easy). Remember, not everything is about properties like nice associativity or similar - readability is paramount.
> **Comments:**
> **username_7** (2023-08-08): Please don’t delete your answer! It has useful examples, and I linked to it from mine, so if you deleted it, I’d have to incorporate them into my answer, anyway. :)  
---
### Answer by username_0 on 2024-03-14. Score: 2
All the above are neat answers. Just to add to the understanding of the importance of bind associativity and especially blueberry's answer, this article helped me understanding why bind is important from a programming language design point of view:

<https://wiki.haskell.org/Monad_laws>

So bind is an implementation of a nice syntactic sugar, the do notation, which is intuitive for programmers.

Forgive me being an algebraist.
> **Comments:**
> **username_8** (2024-03-14): As a trigonometrist myself, all your sins are forgiven.  
---
