What's a monad?

Don't feel bad about not understanding that description - it's like describing driving as "a social pattern for moving people faster than horses".

One example monad is Maybe or Optional (named depending on your programming language). That's useful when you have values which are sometimes present and sometimes missing, but always of a certain type.

Optionals can contain a value, or be empty. Using a Java example because it's what I'm using at the moment, Optional.of(1) is an optional containing a value of 1. Optional.empty() is an empty optional.

If (say, in Java again) you are writing lots of code like `if (x == null) { y = null } else { y = x + 1}`, having to work around possibly missing values, you can rewrite to use the Optional monad instead - here you would do `y = x.map(n -> n + 1)`.

Using Optional in this case gives you type safety to avoid problems with null.

Another important thing about monads is that they can be combined. Say we have a function called `div(x, y)` which returns Optional<Int>. It returns Optional.of(x / y) most of the time, but returns Optional.empty() when dividing by 0.

`Optional.of(2).map(n -> div(n, 2))` returns `Optional.of(Optional.of(2))`

`Optional.of(2).map(n -> div(n, 0))` returns `Optional.of(Optional.empty())`

Here, it's a bit of a pain to get the result of the operation above, because it's "boxed" inside another optional. But all Monads have a flatMap operation, which allows you to sensibly "flatten" values.

`Optional.of(2).flatMap(n -> div(n, 2))` returns `Optional.of(2)`

`Optional.of(2).flatMap(n -> div(n, 0))` returns `Optional.empty()`

So a Monad is just a class of data types which are easily combined (with flatmap) and have a sensible "empty" value

A monad is an abstraction that captures the notion of sequencing computation in some shared context where subsequent computation depends on the result of previous computation.

If you stare at this for a while and end up thinking “Isn’t that what expressions do anyway?” congratulations; you’re half way to understanding monads. The other half is understanding that monads satisfy a few (three, to be exact) algebraic laws that govern their behavior, and in particular, how you can combine, or “compose,” them.

The big surprise is the range of things monads can be brought to bear on that aren’t at all apparent from the description or the Maybe example, like I/O, concurrency, and error handling. In OCaml, you may run into Lwt (the “lightweight threads”) library, for example. Lwt is a monad.

Monads in OCaml tend to be a bit unusual, because OCaml doesn’t have higher-kinded types, so it’s hard to express the standalone abstraction named “monad.” It also lacks syntactic conveniences for monadic programming. Both of these are addressed with some amount of pain by various libraries and extensions you can use. If you’re interested, I recommend studying the Lwt ecosystem with one of the PPX extensions that offers Lwt-based syntax, Try learning how to use Lwt consistently anytime you need to manipulate state, do I/O, do things concurrently, or handle errors.

What’s the point? To be able to reason about your code algebraically. To have 99.99% confidence you know what your code will do before it runs. Defect reduction because your whole program is obeying a small set of simple laws. That’s the name of the game.

I’m happy to elaborate on any of this if you’d like.

This is a FAQ. I'll try to produce a high effort answer here that's easy to reference in the future.

Monads are a lot easier to use than they are to explain. Forget the stuff about category theory, and think of other times in your life you've programmed a sequence of calls and had to check each damn call for errors before proceeding.

For example. Suppose you have a routine that arranges a connection to a server and does a simple login handshake. You give the routine the remote host to connect to and a username and password. It returns either a logged in session object if it succeeds, or NULL if it fails.

The call sequence in the routine body is trivial enough:

if (remote_host == NULL) return NULL;
remote_ip = get_ip(remote_host);
if (remote_ip == NULL) return NULL;
tcp = tcp_connect(remote_ip, 80);
if (tcp == NULL) return NULL;
banner = read_line(tcp);
if (banner == NULL) return NULL;
if (banner.strip() != "HELLO") return NULL;
session = send_login(tcp, user, passwd);
return session

No big deal. People write this code all day every day. But I think it's a bit tedious. A pattern should jump out at you. What if you could factor out that repetitive, noisy NULL check?

function bind(x,f) {
    if (x != NULL) return f(x);
    return NULL;
}

Then you can rewrite the above code as follows:

bind(remote_host, function(remote_host) {
bind(get_ip(remote_host), function(remote_ip) {
bind(tcp_connect(remote_ip, 80), function(tcp) {
bind(read_line(tcp), function(banner) {
if (banner.strip() != "HELLO") return NULL;
return send_login(tcp, user, passwd)
}); }); }); });

This is ugly but it illustrates the point.

Each function body is guaranteed that the argument was non-NULL, by the bind function.

The PL PhD way of talking about this is that it's the monadic bind specialized to nulls (option types). To more normal people this is actually just a non-null dispatch using a continuation passing style.

The important part here is that each inwardly concentric function only gets called if the argument was non-NULL, so it never has to test for NULL itself.

Can we fix the readability problem there? Sure, what if the bind function was actually an infix operator, like >>= ?

Instead of saying bind(x,f) you say x >>= f

Then it looks like this:

remote_host >>= function(remote_host) {
get_ip(remote_host) >>= function(remote_ip) {
tcp_connect(remote_ip, 80) >>= function(tcp) {
read_line(tcp) >>= function(banner) {
if (banner.strip() != "HELLO") return NULL;
return send_login(tcp, user, passwd)
}}}}

That's much clearer IMO, especially if you compare to the first example way at the top.

And… that's probably as good as you can get with curly braced pseudo-code.

What if you could use something like ML or Haskell syntax? Then it looks like:

remote_host >>= fun remote_host ->
get_ip remote_host >>= fun remote_ip ->
tcp_connect remote_ip 80 >>= fun tcp ->
read_line tcp >>= fun banner ->
if banner.strip() <> "HELLO" then NULL
else send_login tcp user passwd

I think that's the clearest yet.

Either way, there, you now know the monadic design pattern.

As an aside, although the OCaml community loves to talk about compilers, GCs, multicore, theory of types and other PL PhD topics, I think where OCaml also shines is helping programmers get through super laborious drudgery like the above. Nothing sexy about it, but still lightens your load.

EDIT: thank you for the gold, kind stranger!

actually you see it is like a burrito

One rather Ocaml-specific way of thinking about monads is that they give you an abstraction that can hide which underlying I/O scheduling framework you're using in your program. There are two big third-party libraries (frameworks) that are popular in Ocaml -- Jane Street's Async, and Ocsigen's Lwt. Both frameworks have a monadic interface for I/O (and for other purposes, too, but let's stick with I/O for now). Libraries from other authors -- such as database adapters or Web client/server libraries -- can work with either I/O framework because they, too, provide an abstract, monadic interface. In theory (!) this interface also lets them support new I/O frameworks that haven't been invented yet.

So a monad -- from this very, very limited perspective -- is just a standardized interface for coordinating I/O across different layers of your program.

There's much more to them than that, of course, and there's nothing particularly "I/O" about monads in general. But sometimes a concrete real-world application is enough to get you started, and the deeper intuition can grow as you use them.

I found Philip Wadler's paper helpful. If it had been linked more often I would have spent a lot less time confused on the matter.

Scott Wlaschin has a talk I think does an alright job explaining it. He commits the sin of using an analogy, but he manages to make it cover a great deal of monad usage. (He's got another video specifically about that but I didn't find it right away. This one covers the way things are done in FP before getting into monads.)

Check this video link https://youtu.be/Ss149MsZluI?t=957 on category theory, where you get some background on monad. I find the whole video is good, since to get the context with monad i am copying the url with specific time where monad/monoid gets targeted.

A few months ago, I wrote a monad tutorial that might be helpful.

As u/billy_tables mentioned, monads support the "map" and "flatmap" operations. Any type that supports the "map" operation is known as a "functor" in functional programming parlance. Most people are used to "map" being an operation on lists, where given a function and a list to map over, each element is transformed by the function in a new list:

val map : ('a -> 'b) -> 'a list -> 'b list

For example, map (fun x -> x + 1) [0; 1; 2] evaluates to [1; 2; 3].

However, if you squint, it's better to understand map as an operation that "lifts" the passed function, which its curried type signature makes apparent (with parentheses for emphasis):

val map : ('a -> 'b) -> ('a list -> 'b list)

Although the list is probably the most famous data structure that can be "mapped" over, it is not the only type that has a map operation defined on it. Another example is the option type:

val map : ('a -> 'b) -> 'a option -> 'b option

The definition of map for the option type is:

let map f = function
  | None -> None
  | Some x -> Some (f x)

If list is a functor and option is a functor, what is the definition of a functor in general? A functor is some polymorphic type 'a t with an operation map : ('a -> 'b) -> 'a t -> 'b t such that the following rules ("laws") hold:

• map (id : 'a -> 'a) = (id : 'a t -> 'a t) (Preservation of identity)
• map (compose g f) = compose (map g) (map f) (Preservation of composition)

These laws might look fancy, but they should be intuitive when you actually work with functors. You can understand them as saying that the map function changes the "contents" of the functor data according to the passed function, but shouldn't change the functor "shape."

A monad is a functor that can be "flattened:"

val flatten : 'a t t -> 'a t

One good example of a monad is the list monad:

let rec flatten : 'a list list -> 'a list = function
  | [] -> []
  | (x :: xs) -> List.append x (flatten xs)

The option type also supports a flatten operation, with a fairly obvious implementation:

let flatten : 'a option option -> 'a option = function
  | None -> None
  | Some opt -> opt

A monad must also support an operation called "return:"

val return : 'a -> 'a t

For lists, the definition of return is:

let return x = [x]

For options, the definition of "return" is:

let return x = Some x

However, monads are often defined in terms of flatmap and return instead of flatten, return, and map.

val flatmap : ('a -> 'b t) -> 'a t -> 'b t

You can define flatmap in terms of flatten and map. flatmap is, fairly obviously, a map followed by a flatten:

let flatmap f x = flatten (map f x)

In the other direction, you can derive flatten from flatmap:

let flatten = flatmap id

and map from flatmap and return:

let map f = flatmap (fun x -> return (f x))

so the two formulations of monad are equivalent.

Another common name for flatten is join. Other common names for flatmap (conventionally with its arguments switched) are bind and >>=.

Why are monads important? If map can be understood as changing the "contents" but not the "shape," flatten can be understood as changing the "shape" by combining nested layers into one. Together, map can "build up" layers and flatten can collapse them. Here is an example in which I attempt to convert a string to an int, then use it to search a hashtable:

let computation = Option.map (Hashtbl.find_opt hashtable) (int_of_string_opt str) in
Option.join computation

or more cleanly:

Option.bind (Hashtbl.find_opt hashtable) (int_of_string_opt str)

A monadic value of type 'a t can be understood as a "computation" that results in an 'a. With map f m, one can pass a function, f, that uses the result of the computation m to produce a new value wrapped up in the monadic type. If f itself returns a computation, 'b t, the result of the entire map is a nested computation, 'b t t. flatten can then collapse the layers to get a 'b t, thus "executing" the computation. The flatmap operation conveniently combines the process of using the result to build up a new computation and then executing it.

Depending on the choice of t, "computation" can mean different things:

• 'a option represents computations that can fail (result in None)
• 'a list represents "nondeterministic" computations (computations that can have multiple "paths")
• ('e, 'a) result represents computations that can fail with an error message (Error e)
• 's -> ('s * 'a) represents computations that may modify a "state" of type 's
• 'a Lwt.t from the Lwt library represents asynchronous computations, or "promises"

These different meanings are called "effects," and monads are said to be an "effect system." Via monads, you can track whether a computation may fail, or may modify some state, etc. in the type system.

May I ask–what materials are you using to learn OCaml?

Btw, here's what the creator of OCaml has to say about monads: https://discuss.ocaml.org/t/io-monad-for-ocaml/4618/7?u=yawaramin

A TL;DR .mli example of what a monad looks like:

(* An group of 'a with the context of t *)
type 'a t = ...

(* Put a 'a into the default context with just one 'a *)
val return: 'a -> 'a t;;

(* Run a function on everything in the context *)
val map: 'a t -> ('a -> 'b) -> 'b t

Some examples (with similar cases ordered the same):

An example implementation for list:

type 'a t = 'a list;;

let return foo = [foo];;

let rec map l f = match l with
    | [] -> []
    | head::body -> (f head)::(map body f);;

An example for option:

type 'a t =
    | Some 'a
    | None;;

let return a =
    Some a;;

let map a f = match a with
    | None -> None (* like List.map [] f *)
    | Some e -> Some (f e);;

An example of a way to defer computation:

(* The first thing is the data, the second is the context of what functions to run *)
type 'a t = 'a * (('a -> 'a) list);;

let return a = a, [];;

let map a f =
    let v, fl = a in
    v, (f::fl);;

(* And an example of getting the data out
 * It applies the functions in reverse since we map them in reverse *)
let unwrap = function
    | a, [] -> a
    | a, (head::body) -> head (unwrap (a, body));;

These are examples of monads with any number of elements, at most one element, or exactly one element, respectively.