Haskell Concepts in One Sentence

Monad, like any interface, is useful because we can abstract over it. Let's take an example from Java: both ArrayList and LinkedList implement List. This means I can write code that is agnostic to the implementation of List, and later I can drop in any implementation I want. Seen from the other direction: if I write something that resembles a list and I implement the List interface, all of the code that's compatible with List will also be compatible with my new implementation.

Similarly, if I define a new data type, and realize that it can implement Monad (or more precisely: that it has a monad instance), then I'll be rewarded with a giant library of code that's already compatible with my new data type [1]. Monad is an especially interesting interface because (1) it turns out many things conform to it [2] and (2) it comes with a set of algebraic laws. There is some controversy over how strict we need to be about the algebraic laws, but in some sense the algebraic laws are part of why such a general interface can be meaningful at all.

So yes, it's true that Monad allows us to sequence effects in a lazy pure language, and that's important, but I think a more down to earth reason to be interested is that it allows for more code reuse [3].

[1] Some of the function defined in the standard library: https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...

[2] See the 'instances' section here: https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro... These are just the instances in the standard library.

[3] It's also worth mentioning that Monad gets all the attention, but Haskell if flush with other mathematically inspired interfaces that are just as general.

>At this point, tutorials use examples like "like flatMap and Maybe in other languages!" which is even more confusing. Why do I need a monad then, if there are similar constructs in other languages that don't need the understanding of monad? Why the complexity? What do I get from monads?

Monads are a mathematical concept, like a ring. "Maybe" is a monad in whatever language you use it in, just like integers are a ring in whatever language you use them in. Pointing out that complex numbers, rational numbers, nxn matrices are all examples of rings and wrapping everything up into a type class doesn't add to the complexity of the language.

The 'why' question is my pet peeve too - often because the answer to

> Why do I need a monad then, if there are similar constructs in other languages that don't need the understanding of monad?

is that you usually don't.

Where I work, people use a handful of monads daily, but most people know the monad laws, nor do they need to.

But now that they know a few specific monads, the "why" of monads is really, well, we needed certain convenience methods (namely bind aka flatMap) to make using e.g. Maybe or promises not a huge pain. And we chose a uniform way to do it across different wrapper types, so that we minimize the cognitive overhead.

It lets you model sequential operation and side effects in a pure functional language. You can usually write your code "manually" without monads, and see what it's like. For example, the State monad is basically a function that takes in a value and some state, and returns a new value and a new state. That's a pure function, but composing/chaining them together is pretty messy. If you do that manually once, you'll then get some intuition why the State monad is useful. Then you can expand to other types of monads and eventually have an intuition for their general value.

Edit: You don't really need monads any more than you need classes, interfaces, functions, procedures (just use goto!), etc. they just help bring a bunch of seemingly disparate functionality together into one standard (which is helpful in, e.g. Scala or Haskell where there's some syntactic sugar for dealing with monads). People complained for the longest time (amongst many, many other things) that Javascript lacked classes, even though you could totally hack it together with `new`, functions and prototypes. Similarly, FP people complain that everything else lacks monad support, even though they can hack it together with largely language independent features (typically without compile-time checking).

I don't have an intuitive grasp of the formal definition of monads, but some examples of things that I _think_ are monads (in Java ... sorry :/ it's all I work with these days):

* jOOQ [1]: you use it to build up a sequence of SQL statements with a pleasant chaining API, then execute the whole shebang * Promise/future chaining: you build up a sequence of promises that should apply in-order, then defer their execution until later (unless you use a language that performs a transformation at compile time which effectively does this for you). * Streams/optional mapping: you build up a sequence of functions that should apply in-order to every element in a potentially empty sequence (optional: a sequence of 0 or 1). * The builder pattern: you build up a sequence of property values, then (potentially) construct the entire object.

[1]: https://www.jooq.org/

> Why do I need a monad then, if there are similar constructs in other languages that don't need the understanding of monad? Why the complexity? What do I get from monads?

They remove the need to type the same shit over and over again. With a list monad you avoid having to write the loop constructs, for the Option/Maybe monad (optional value) you avoid having to write if/then/else, for the Either/Choice monad you avoid having to write if/then/else and manually propagating an error value on failure, for the State monad you avoid having to pass a context value through as an argument to every function, for the Try monad you get exception handling and error propagation like the Either/Choice monad, with the Writer monad you are able to do logging without a global logging system or having to manually pass through a logging context, etc.

Ultimately they're there to reduce boilerplate and to help write more composable and reliable code. There are other benefits, but this encapsulation and abstraction of common patterns is what most programmers strive for, no matter what language they use, so I feel it's important to put them in that context.

Let me give you a very simple example. I'm going to use C# because it's been a long time since I've done any Haskell and I'll probably get it wrong.

I'm going to create a monad called NoNull. If at any point it sees a value that is null then it will stop the computation and return without completing. It's a slightly pointless example because C# has the null propagating operator, but conceptually it should be easy for any programmer to grasp that using null is bad, so being able to 'early out' of a computation when you get a null value is desirable.

First I'll define the type:

    public class NoNull<A> where A : class
    {
        public readonly A Value;

        public NoNull(A value) =>
            Value = value;

        public static NoNull<A> Return(A value) =>
            new NoNull<A>(value);

        public NoNull<B> Bind<B>(Func<A, NoNull<B>> bind) where B : class =>
            Value is null
                ? NoNull<B>.Return(null)
                : bind(Value);

        public NoNull<B> Select<B>(Func<A, B> map) where B : class =>
            Bind(a => NoNull<B>.Return(map(a)));

        public NoNull<C> SelectMany<B, C>(Func<A, NoNull<B>> bind, Func<A, B, C> project) 
            where B : class 
            where C : class =>
                Bind(bind).Select(b => project(Value, b));

    }

It's a class that has a single field called Value. The two functions to care about are:

    Return - Which constructs the NoNull monad
    Bind - Which is the guts of the monad, bind does the work

Select and SelectMany are there to make it work with LINQ. I have implemented them in terms of Bind.

As you can probably see Bind is encapsulating the test for null, and if null is found then the result is Return(null), it doesn't run the `bind` delegate.

Next we'll create some NoNull monadic strings:

    var w = NoNull<string>.Return("hello");
    var x = NoNull<string>.Return(", ");
    var y = NoNull<string>.Return("world");
    var z = NoNull<string>.Return(null);

The last one contains null, the bad value.

I can now use those values like so:

     var result = from a in w
                  from b in x
                  from c in y
                  select a + b + c;

Notice there's no checks for null, the monad does that work for us.

In this instance, result.Value is equal to "hello, world".

Now if I inject a bad value into our monadic computation:

    var result = from a in w
                 from b in x
                 from c in y
                 from d in z             // <--- this is null
                 select a + b + c + d;

Then result.Value is equal to null and the `a + b + c + d` didn't run at all.

The alternative is this:

    string w = "hello";
    string x = ", ";
    string y = "world";
    string z = null;

    string result = null;
    if (w != null)
    {
        if (x != null)
        {
            if (y != null)
            {
                if (z != null)
                {
                    result = w + x + y + z;
                }
            }
        }
    }

Where the programmer constantly has to do the work that the monad will do for free. I've nested those if statements to try and give you the impression of what the series of 'from' expressions are in the example above (in Haskell it's known as 'do notation'). Each 'from' creates a context over the whole of the rest of the expression.

For the avoidance of doubt about the nesting, I could have written it thus:

    var result = w.Bind(a =>
                 x.Bind(b =>
                 y.Bind(c =>
                 z.Bind(d =>
                 NoNull<string>.Return(a + b + c + d)))));

Here [1] is an example of a Parser monad in action in C# (it's part of a parser that parses C# source that I use to generate API reference docs for my github projects [2]). This runs code 'in the gaps' between each 'from' statement. What it does in those gaps is check if the parser above it failed, and if so it bails out with an appropriate error message based on what it expected. But you don't see any if(result.IsFaulted) ... code anywhere, or maintenance of the position of the parser in the input stream, because that is encapsulated in the Parser monad. It makes the code very clear (I think) in that it's not cluttered with the regular scaffolding of control structures that you usually see in imperative languages.

What's really quite beautiful about monads is the way they compose, and I think this is especially beautiful with parser combinators. A Parser<Char> which parses a single character has the same interface as a Parser<SourceFile> which parses an entire source file. Being able to build simple parsers and then combine them into more complex ones is just a joy to do. Clearly parsing isn't unique to monads, but there's an elegance to it (and monads in general) which I think is hard to resist.

[1] https://github.com/louthy/best-form/blob/master/bestform.cs/...

[2] https://louthy.github.io/language-ext/LanguageExt.Core/Langu...

I think if you already know fmap, join and Haskell syntax, you also already know monads, so I'm not sure whom this is easier for :P

So bind is flat map in other languages? If join is a function that take a list and appends its elements together join ( [[1], [2], [3]] ) -> [1,2,3]

then bind is join(map(f, x))?

bind just seems like a terrible name.

For some reason Haskell users try to make things sounds as academic as possible.

What is the data structures don't support a join operation, like a tree?

A higher-level type (which is a function, if you allow functions in your type system). Examples:

List of a

One or zero of a

A randomly chosen a

A function that takes an s and returns an a and another s i.e. s -> (s, a) aka "a stateful computation returning a) A routine that reads a file and returns an a.

In each case, the point is that you can a) write code that acts as if the k isn't there and hence b) re-use code between all of these things without changing it.

I'm going to take the opportunity to recommend http://www.cis.upenn.edu/~cis194/spring13/. Do all of the exercises, even the really basic ones. What you learn by the end will blow your mind.

You can explain what a monad, for example, is, in one sentence, but it is useless if you don't show how it is used.

Similarly, you may know what eigenvector, or derivative function, is, but without practice you can't understand why you may want it.

> why can't there be a shorter explanation for people who already know programming.

Why can't you learn chinese very fast if you already know a handful of european languages ? The answer is the same : the underlying concepts are different.

Sadly, there is no easy shortcut to understand these concepts. The best that can be done (and it's hard enough already), is to make learning entertaining.

Yet people learn best from examples, so I don't get why every monad explanation is in reverse like that.

The Z is Y. The Y is an X that does W. ...omitted... Here's C, B and A. Now you understand!

First comment in this thread is exactly like that. Definitions, not explanations.

And then after telling you how monads are different than map for things that are _not_ lists, a bunch of follow up comments talk about... Lists.

Pedagogy does not work like that. What is it about haskell that ruins people's ability to explain things?

Just to expand a little bit upon the sibling comment.

Let's say you need a function that maintains internal state. Now, in non-pure languages, you could that by simply referring to some global variable, but let's agree that's bad. So how can you model internal state purely?

Simple, your function takes the current state and produces a new state, along with its result. So, a pure function like:

    f(String) => Int

turns into the stateful function:

    f(String) => (State => [Int, State])

I.e. a function that returns a function that takes in a state and produces a result and a new state.

Cool, but now let's say we have another function g:

    g(Int) => (State => [Double, State])

Let's now say we want to compose those two functions:

    let result = g(f("5"));

However, this won't work, becase f produces (State => [Int, State]) but g expects Int.

So, here's bind for the State monad (implementation is not important):

    bind(State => [a, State], a => (State => [b, State])) => (State => [b, State])

If we define a "type alias" (just a synonym, so we don't have to type that much) for a stateful function:

    type StatefulFunction<a> = State => [a, State]

and then replace the above bind definition with it:

    bind(StatefulFunction<a>, a => StatefulFunction<b>) => StatefulFunction<b>

you can see that is has the same structure as flatMap!

    flatMap(List<a>, a => List<b>) => List<b>

With the type alias, f and g would then look like this:

    f(String) => StatefulFunction<Int>
    f(Int)    => StatefulFunction<Double>

So now, here's how you compose f and g:

    bind(f("5"), a => g(a))

In Haskell, there's syntax sugar for bind, so the above turns into

    do
      a <- f "5"
      g a

which is very similar to a conventional language:

    {
       a = f(5);
       g(a);
    }

EDIT: forgot result type in bind and flatMap.

That's the thing with powerful abstractions: they apply to so many things that seem unrelated, that it may be difficult to see the connection. But that's where all the power lies: being able to use a common abstraction across so many different problems gives you extremely powerful means to express generic operations.

Say you wanted to iterate over a list of image files and apply a transformation to them. In haskell, doing that work synchronously and doing it asynchronously can use the same function, just in a different monad, because the definition of bind determines the execution strategy.

The monad abstraction provides a way to encode a dependency between "operation 1" and "operation 2", or inject behaviour between "element 1" and "element 2" when processing a data structure.

The type signature of bind is "m a -> (a -> m b) -> m b". It might look complicated, but it states "given a monadic value with an inner type of a, and a function from a to a monadic value with inner type of b, you will get a monadic value with inner type of b"

This can be used to access data "inside" a type where you might not have direct access, in such a way that bind determines how the access happens so that it can enforce things like "The preceding IO must have been finished" or "The future must be completed" or "The list values must be concatenated" or "You must compose the continuations properly" or "If any operation results in Nothing, the result is Nothing"

Haskell IO is the usual example of this. Since the IO type is opaque, you cannot construct values of IO yourself directly. An IO String (such as getLine) represents an IO operation that results in a String value. Similarly, the "putStr" function (of type String -> IO ()) is a function that takes a string and results in an IO action that "does something and the value does not matter", or in this case, prints the string to the screen.

However, you can't just compose getLine and putStr directly, because the types don't match. You need to get the value "inside" getLine first.

This is what the bind function allows you to do. And it's defined for the IO type, in such a way that IO ordering is enforced. You can't not use bind, because you have no way of accessing the String value inside getLine without it.

I don't know if my explanation helps. The seeming "complexity" of monads arises from the fact that you can apply the same simple abstraction to so many different things, often in seemingly unintuitive ways.

>This seems too simple.

There is a reason people say monads are simple.

The comment you are replying to is describing the concrete example of the List monad. To answer you direct questions, it is probably better to look at another example: the State monad.

The idea behind state is simple. Suppose you have a bunch of functions that you want to call in sequence. This is a simple enough problem; just do f(g(h(x))) or `h(x) |> g |> f` [0].

Now, suppose that, in addition to piping a value from one function to the next, we want to keep track of additional state. For example, maybe we want to use a psuedo-random number generator in some of the functions and have to keep track of its internal state. One way to do that would be to simply modify each function so that the returned value includes the state; but this quickly becomes unwieldy. The State monad provides a way to automatically thread the state through the functions. So we can do:

    put initSeed >>= h >>=  (get \currentSeed -> g currentSeed) >>= (get \nextSeed -> f nextSeed)

or (with a bit of syntactic sugar:

    put initSeed
    h
    currentSeed <- get
    g currentSeed
    nextSeed <- get
    f nextSeed

in this example g and f would be expected to call put to update the internal state.

Now, suppose you want to keep applying a function until some condition becomes true about the state. In this case, it makes sense to talk about a while loop:

    while (get >>= \state -> state =/= 7) f

The above snippet will repeatadly bind f until the internal state is 7.

It turns out, that we can implement while in terms of only the Monad interface:

    while condition action = do
        x <- condition
        if x then (action >> (while condition action))
            else return () 

It turns out that most control structures can be encoded into monads in this way.

The IO system is a bit hacky. The idea is that the universe is a big state machine. So, when we do `println "Hello World"`, we are not causing a side effect, we are just updating our internal state to say that we printed "Hello World". Simmilarly, getLine just peaks into our internal state to see what the input at the current time has always been. Of course, for some reason, GHC does not give us the full get or put functions for the IO monad; but they could exist in theory, and that is enough to pretend that side effects do not exist.

[0] Not actual haskell because we can't agree on a name for the pipeline operator I am calling "|>" here.

> This seems too simple.

So this is one example of a Monad. Go through the same process with different "datastructures" to see the power of it. First try with a "Maybe" monad, and then a "State" monad. The generalization of that idea is the monad.

The power comes not from the complexity, but from the realization that this simple idea applied in alternate contexts (ie on different datastructures) allows many powerfull solutions to problems.

The idea is fundamentally simple - applying that same simple idea in different contexts provides the value. It is a simple idea, it's just impressive how many different contexts it works in to solve problems. Problem domains that we normally would have felt have nothing in common.

Simple /= easy. Complex /= hard.

Monads are very simple. They just aren't easy because most people don't have the base of terminology. When you grok them you'll laugh because you'll realize how simple and powerful and obvious they seem in hindsight.

This is the reason so many people write monad tutorials after they learn them. It's actually really weird. Does anyone else have some examples of things they learned which seemed really difficult but turned out to be really simple in hindsight?

Well, you really should know the amount of Haskell it assumes you know (typeclasses, maybe infix functions, arity etc) before learning about Haskell monads. Otherwise you're learning multiple concepts at once - why not learn about those other concepts in other contexts first? The Stephen Diel article even lists the prerequisites explicitly.

My favourite monad explanation is Tikhon Jelvis's at https://www.quora.com/What-are-monads-in-functional-programm..., but reading through it, it does assume some prerequisite knowledge about Haskell.

I posted that because I think it's the best you're going to get.

Monads can be two things: (1) a concept in category theory, (2) a rough implementation of that concept in a programming language.

If you want to learn about monads from the category theory perspective, great! This is really hard though, I wouldn't recommend it for most people (and haven't really even succeeded myself).

If you want to learn about a specific programming language's implementation of monads, you will naturally have to know how that language works. This road is far easier than category theory, but still requires knowing (for Haskell) what a typeclass is, what a higher-kinded type is, etc.

It sounds like you want an explanation without prereqs from either category theory or Haskell. If you google for monad tutorials you will find dozens of quick explanations, but I personally don't think this is a good way to actually understand them.

To understand monads one must first understand monads.

I'm not even saying that a bit sarcastically. I've read countless "tutorials" and even tried messing around with Haskell in an attempt to grok monads. According to the link shared by GP comment, my understanding is still completely wrong.

There is a reason there is a joke about it.

"A monad is just a monoid in the category of endofunctors, what's the probleⅿ?" - James Iry, taken from [0]

[0] http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

As a scala developer the thing which got me on my way was the explanation "something which has a flatMap method". That's not entirely true but it gets you in the right ballpark.

If I define this in c++ lingo words barely change.

You take a c++ parent class with two virtual methods. These methods are "return" and "bind". In order to implement a monad instance you must derive from this parents class and implement the virtual methods.

The author is mistaken. There are only two functions necessary for a monad: >>= and return

Also, the type of return is `a -> m a`. The type you cite `a -> m b` is a parameter to >>= (which has type `m a -> (a -> m b) -> m b.

The author might be refering to a quirk of the Haskell monad interface, which has to additional functions:

">>" which can be easily defined in terms of >>=. I assume this is part of the interface so users can override it with a more efficient implementation, but every implementation I have seen just uses the default one.

"fail" which is an error handler. This is being depreciated as a function of Monads, and moved into its own MonadFail typeclass. This also has a default implementation that just throws an exception.

I see, thanks for the explanation. That's a good analogy. Cheers.