If you are confident, that you will not need the counter state at the end and
that you will not combine blocks of code using the counter
(where the second block needs the state at the end of the first block),
you can enforce a more strict scheme of usage.

1.3 Safety

With

do

notation we have kept alive a dark side of the C programming language:

The silent neglect of return values of functions.
In an imperative language it is common to return an error code and provide the real work by side effects.
In Haskell this cannot happen, because functions have no side effects.
If you ignore the result of a Haskell function the function will even not be evaluated.

The situation is different for

IO

:
While processing the

IO

you might still ignore the contained return value.

You can write

dogetLineputStrLn"text"

and thus silently ignore the result of

getLine

.

The same applies to

do System.cmd.system "echo foo >bar"

where you ignore the

ExitCode

.

Is this behaviour wanted?

In safety oriented languages there are possibilities to explicitly ignore return values
(e.g. EVAL in Modula-3).
Haskell does not need this, because you can already write

do_<- System.cmd.system "echo foo >bar"return()

Writing

_<-

should always make you cautious whether ignoring the result is the right thing to do.
The possibility for silently ignoring monadic return values is not entirely the fault of the

do

notation.
It would suffice to restrict the type of the

(>>)

combinator to

(>>):: m ()-> m a -> m a

This way, you can omit

_<-

only if the monadic return value has type

()

.

2 Happy with less sugar

2.1 Additional combinators

Using the infix combinators for writing functions simplifies the addition of new combinators.
Consider for instance a monad for random distributions.

This monad cannot be an instance of

MonadPlus

,
because there is no

mzero

(it would be an empty list of events, but their probabilities do not sum up to 1)
and

mplus

is not associative because we have to normalize the sum of probabilities to 1.
Thus we cannot use standard

guard

for this monad.

However we would like to write the following:

do f <- family
guard (existsBoy f)return f

Given a custom combinator which performs a filtering with subsequent normalization called

(>>=?):: Distribution a ->(a ->Bool)-> Distribution a

we can rewrite this easily:

family >>=? existsBoy

Note that the

(>>=?)

combinator introduces the risk of returning an invalid distribution (empty list of events),

but it seems that we have to live with that problem.

2.2 Alternative combinators

If you are used to write monadic function using infix combinators

(>>)

and

(>>=)

you can easily switch to a different set of combinators.

This is useful when there is a monadic structure that does not fit into the current

Monad

type constructor class,

where the monadic result type cannot be constrained.
This is e.g. useful for the Set data type,
where the element type must have a total order.

3 Useful applications

It shall be mentioned that the

do

sometimes takes the burden from you to write boring things.

E.g. in

getRight ::Either a b ->Maybe b
getRight y =do Right x <- y
return x

a

case

on

y

is included,
which calls

fail

if

y

is not a

Right

(i.e.

Left

),
and thus returns

Nothing

in this case.
Also the

mdo

notation proves useful, since it maintains a set of variables for you in a safe manner.