<p>Usually you don't see <code>&gt;&gt;=</code> (bind) and <code>&gt;&gt;</code> (then) inside <code>do</code> blocks--<code>do</code> gives you a more flexible interface with monads and lets you weave in other logic, as you can see in the function you're referring to:</p>
<pre><code>payContract :: Contract () PaySchema Text ()
payContract = do
    pp &lt;- awaitPromise $ endpoint @&quot;pay&quot; return
    let tx = mustPayToPubKey (ppRecipient pp) $ lovelaceValueOf $ ppLovelace pp
    void $ submitTx tx
    payContract
</code></pre>
<p>The advantage of a <code>do</code> block is having a more imperative and readable view into the monad.</p>
<p>I usually associate <code>&gt;&gt;=</code> and <code>&gt;&gt;</code> with monad combination outside of <code>do</code> blocks, but I guess there is no reason you <em>couldn't</em> use them inside the block. Feels like mixing and matching, but maybe that's just me; if you're already inside a <code>do</code> block, you might as well use <code>void</code>, <code>&lt;-</code>, etc</p>

CC BY-SA 4.0
2022-02-11T19:15:42.163Z
2022-02-11T19:15:42.163Z
Mitchell Turner
<p>There are no benefits of using one over the other. They are equivalent and its simply a matter of choice.</p>

CC BY-SA 4.0
2022-02-14T01:33:22.597Z
This is an opinion rather than a factual response.  I guarantee that one is more 'readable' than the other and expresses the logic more clearly.  I have always written for clarity first and optimized later.  One may also cost fewer cycles than the other.
gRebel
CC BY-SA 4.0
2022-02-15T05:22:33.203Z
That there is no benefit of one over the other is a factual response. The compiler desugars the `>>`  version to the other so there is zero difference in performance.

Yes, you might find one more readable than the other, but that is an opinion.
Erik de Castro Lopo
CC BY-SA 4.0
2022-02-12T01:25:33.140Z
2022-02-12T01:25:33.140Z
Erik de Castro Lopo
<p>Given a <code>do</code> block which contains these expressions:</p>
<pre><code>void $ submitTx tx
payContract
</code></pre>
<p>Would it be feasible to reformat this lines using the then operator, and thus telling the compiler to do something, ignore the output and proceed to do something else? Something like:</p>
<pre><code>submitTx tx &gt;&gt; payContract
</code></pre>
<p>If so, what are the benefits of using one over the other? Is any option considered a good or bad practice?</p>

CC BY-SA 4.0
2022-02-11T13:57:35.297Z
I would say that it’s a matter of taste.
kindofdev
<haskell>
Using `void` vs using `>>` (then) operator
# Using `void` vs using `>>` (then) operator

(Asked by: username_0 on 2022-02-11)

Given a do block which contains these expressions:
void $ submitTx tx
payContract

Would it be feasible to reformat this lines using the then operator, and thus telling the compiler to do something, ignore the output and proceed to do something else? Something like:
submitTx tx >> payContract

If so, what are the benefits of using one over the other? Is any option considered a good or bad practice?

**Tags:** haskell
> **Comments:**
> **username_1**: I would say that it’s a matter of taste.  

---

## 2 answers

### Answer by username_2 on 2022-02-11. Score: 1 | Accepted answer

Usually you don't see >>= (bind) and >> (then) inside do blocks--do gives you a more flexible interface with monads and lets you weave in other logic, as you can see in the function you're referring to:
payContract :: Contract () PaySchema Text ()
payContract = do
    pp <- awaitPromise $ endpoint @"pay" return
    let tx = mustPayToPubKey (ppRecipient pp) $ lovelaceValueOf $ ppLovelace pp
    void $ submitTx tx
    payContract

The advantage of a do block is having a more imperative and readable view into the monad.
I usually associate >>= and >> with monad combination outside of do blocks, but I guess there is no reason you couldn't use them inside the block. Feels like mixing and matching, but maybe that's just me; if you're already inside a do block, you might as well use void, <-, etc


---

### Answer by username_3 on 2022-02-12. Score: 0

There are no benefits of using one over the other. They are equivalent and its simply a matter of choice.

> **Comments:**
> **username_4**: This is an opinion rather than a factual response.  I guarantee that one is more 'readable' than the other and expresses the logic more clearly.  I have always written for clarity first and optimized later.  One may also cost fewer cycles than the other.  
> **username_3**: That there is no benefit of one over the other is a factual response. The compiler desugars the `>>`  version to the other so there is zero difference in performance.  Yes, you might find one more readable than the other, but that is an opinion.  

---

