If you have followed the Haskell community much, you may have heard the phrase "programmable semicolon" in relation to monads. Of course, it is not obvious what is meant by such a thing, so I figured I'd write a short explanation for those already familiar with monads.

First, let's look at an example of how the semicolon works in Rust (because I don't know C):

fn main() {
let x = 13;
println!("{}", x)
}

The semicolon separates statements. This means that we can have multiple statements within one function (here, we first have a let statement and then our returned value).

In Haskell, the closest thing to a semicolon is the >> operator. We can write something like the above Rust code in the following manner:

import           Control.Monad.State.Lazy
import qualified Data.Map                 as Mmain :: IO ()
main = evalStateT st memptyst :: StateT (M.Map String Int) IO ()
st = modify (M.insert "x" 13) >>
(liftIO . print =<< gets (M.lookup "x"))

The first thing we should note is that >> is more generic - the type signature is (>>) :: m a -> m b -> m b, and we can use it for state monad actions. That's where part of the "programmable semicolon" comes from: in Rust, we have statements, and they are executed in sequence; in Haskell, we have monadic actions, and they are strung together with functions. In Rust, the programmer has no way of changing this sequencing behavior; ; has to be a compiler built-in and hence it forces an implicit assumption about how programs work onto all programs written with in Rust.

This is a subtle point. After all, what is to stop the programmer from writing monads once Rust has higher-kinded types? What Haskell has - that Rust, Elm, PureScript, Scala, and F# don't - is laziness. This allows us to write (>>) :: m a -> m b -> m b as a function. This is not possible when the arguments are evaluated strictly; as an illustration consider the following program:

import           System.Exit
main :: IO ()
main =
exitSuccess >>
undefined

Had >> been strict in its arguments, it would have failed immediately. Hence, laziness allows us to use plain functions to manipulate actions, avoiding the need for compiler built-ins like ;.

All this might also help to explain another Haskell maxim: "Haskell is the best imperative language." In Haskell (or Idris), functions are truly first-class, to the point where we can use them in places traditionally assumed to be the domain of the compiler.