Return to Answer

1. You take some kind of value and wrap it with some additional information. Just like the value is of a certain kind (eg. an integer or a string), so the additional information is of a certain kind.

   F.ex. that extra information might be a Maybe or an IO.

2. Then you have some operators that allow you to operate on the wrapped data while carrying along that additional information. These operators use the additional information to decide how to change the behaviour of the operation on the wrapped value.

   F.ex., a Maybe Int can be a Just Int or Nothing. Now, if you add a Maybe Int to a Maybe Int, the operator will check to see if they are both Just Ints inside, and if so, will unwrap the Ints, pass them the addition operator, re-wrap the resulting Int into a new Just Int (which is a valid Maybe Int), and thus return a Maybe Int. But if one of them was a Nothing inside, this operator will just immediately return Nothing, which again is a valid Maybe Int. That way, you can pretend that your Maybe Ints are just normal numbers and perform regular math on them. If you were to get a Nothing, your equations will still produce the right result – without you having to litter checks for Nothing everywhere.

1. You take some kind of value and wrap it with some additional information. Just like the value is of a certain kind (eg. an integer or a string), so the additional information is of a certain kind.

   E.g., that extra information might be a Maybe or an IO.

2. Then you have some operators that allow you to operate on the wrapped data while carrying along that additional information. These operators use the additional information to decide how to change the behaviour of the operation on the wrapped value.

   E.g., a Maybe Int can be a Just Int or Nothing. Now, if you add a Maybe Int to a Maybe Int, the operator will check to see if they are both Just Ints inside, and if so, will unwrap the Ints, pass them the addition operator, re-wrap the resulting Int into a new Just Int (which is a valid Maybe Int), and thus return a Maybe Int. But if one of them was a Nothing inside, this operator will just immediately return Nothing, which again is a valid Maybe Int. That way, you can pretend that your Maybe Ints are just normal numbers and perform regular math on them. If you were to get a Nothing, your equations will still produce the right result – without you having to litter checks for Nothing everywhere.

1. You take some kind of value and wrap it with some additional information. Just like the value is of a certain kind (eg. an integer or a string), so the additional information is of a certain kind.

   F.ex. that extra information might be a Maybe or an IO.

2. Then you have some operators that allow you to operate on the wrapped data while carrying along that additional information. These operators use the additional information to decide how to change the behaviour of the operation on the wrapped value.

   F.ex., if you add a Maybe Int to a Maybe Int, then the operator will look at the Maybes wrapping the Ints to see if they both have a valid value. If so, it passes the unwrapped Ints to the addition operator and then returns the resulting Int wrapped in a Maybe that says it’s valid; otherwise it just returns a Maybe Int that says it’s empty.

But the example is what happens for a Maybe. If the extra information was an IO, then that special operator defined for IOs would be called instead, and it could do something totally different before performing the addition. (OK, adding two IO Ints together is probably nonsensical – I’m not sure yet.)

Basically, "monad" roughly means "pattern". But instead of a book full of informally explained and specifically named Patterns, you now have a language construct – syntax and all – that allows you to declare a pattern as a thing in your program. (The imprecision here is all the patterns have to follow a particular form, so it’s not quite patterns. But I think that’s the closest term that most people know.)

And that is why people find them so confusing: because they are such a generic concept.

But imagine what this means: instead of having to read the Gang of Four book and memorise the construction of all the patterns, you just write code that implements these patterns in an agnostic, generic way once and then you are done! You can then reuse this pattern, like Visitor or Strategy or Façade or whatever, by decorating the operations in your code with it without having to implement it over and over!

So that is why people who understand monads find them so useful: it’s not some ivory tower concept that intellectual snobs pride themselves on understanding (OK, that too, of course, teehee), but actually makes code simpler.

1. You take some kind of value and wrap it with some additional information. Just like the value is of a certain kind (eg. an integer or a string), so the additional information is of a certain kind.

   F.ex. that extra information might be a Maybe or an IO.

2. Then you have some operators that allow you to operate on the wrapped data while carrying along that additional information. These operators use the additional information to decide how to change the behaviour of the operation on the wrapped value.

   F.ex., a Maybe Int can be a Just Int or Nothing. Now, if you add a Maybe Int to a Maybe Int, the operator will check to see if they are both Just Ints inside, and if so, will unwrap the Ints, pass them the addition operator, re-wrap the resulting Int into a new Just Int (which is a valid Maybe Int), and thus return a Maybe Int. But if one of them was a Nothing inside, this operator will just immediately return Nothing, which again is a valid Maybe Int. That way, you can pretend that your Maybe Ints are just normal numbers and perform regular math on them. If you were to get a Nothing, your equations will still produce the right result – without you having to litter checks for Nothing everywhere.

But the example is just what happens for Maybe. If the extra information was an IO, then that special operator defined for IOs would be called instead, and it could do something totally different before performing the addition. (OK, adding two IO Ints together is probably nonsensical – I’m not sure yet.) (Also, if you paid attention to the Maybe example, you have noticed that "wrapping a value with extra stuff" is not always correct. But it’s hard to be exact, correct and precise without being inscrutable.)

Basically, "monad" roughly means "pattern". But instead of a book full of informally explained and specifically named Patterns, you now have a language construct – syntax and all – that allows you to declare new patterns as things in your program. (The imprecision here is all the patterns have to follow a particular form, so a monad is not quite as generic as a pattern. But I think that’s the closest term that most people know and understand.)

And that is why people find monads so confusing: because they are such a generic concept. To ask what makes something a monad is similarly vague as to ask what makes something a pattern.

But think of the implications of having syntactic support in the language for the idea of a pattern: instead of having to read the Gang of Four book and memorise the construction of a particular pattern, you just write code that implements this pattern in an agnostic, generic way once and then you are done! You can then reuse this pattern, like Visitor or Strategy or Façade or whatever, just by decorating the operations in your code with it, without having to re-implement it over and over!

So that is why people who understand monads find them so useful: it’s not some ivory tower concept that intellectual snobs pride themselves on understanding (OK, that too of course, teehee), but actually makes code simpler.

[Disclaimer: I am still trying to fully grok monads. The following is just what I have understood so far. If it’s wrong, hopefully someone knowledgeable will call me on the carpet.]

Arnar wrote:

Monads are simply a way to wrapping things and provide methods to do operations on the wrapped stuff without unwrapping it.

That’s precisely it. The idea goes like this:

1. You take some kind of value and wrap it with some additional information. Just like the value is of a certain kind (eg. an integer or a string), so the additional information is of a certain kind.

   F.ex. that extra information might be a Maybe or an IO.

2. Then you have some operators that allow you to operate on the wrapped data while carrying along that additional information. These operators use the additional information to decide how to change the behaviour of the operation on the wrapped value.

   F.ex., if you add a Maybe Int to a Maybe Int, then the operator will look at the Maybes wrapping the Ints to see if they both have a valid value – if so, it passes them to the addition operator, otherwise it returns an Maybe Int that says it’s empty.

But the example is what happens for a Maybe. If the extra information was an IO, then that special operator defined for IOs would be called instead, and it could do something totally different before performing the addition. (OK, adding two IO Ints together is probably nonsensical – I’m not sure yet.)

Basically, "monad" roughly means "pattern". But instead of a book full of informally explained and specifically named Patterns, you now have a language construct – syntax and all – that allows you to declare a pattern as a thing in your program. (The imprecision here is all the patterns have to follow a particular form, so it’s not quite patterns. But I think that’s the closest term that most people know.)

And that is why people find them so confusing: because they are such a generic concept.

But imagine what this means: instead of having to read the Gang of Four book and memorise the construction of all the patterns, you just write code that implements these patterns in an agnostic, generic way once and then you are done! You can then reuse this pattern, like Visitor or Strategy or Façade or whatever, by decorating the operations in your code with it without having to implement it over and over!

So that is why people who understand monads find them so useful: it’s not some ivory tower concept that intellectual snobs pride themselves on understanding (OK, that too, of course, teehee), but actually makes code simpler.

[Disclaimer: I am still trying to fully grok monads. The following is just what I have understood so far. If it’s wrong, hopefully someone knowledgeable will call me on the carpet.]

Arnar wrote:

Monads are simply a way to wrapping things and provide methods to do operations on the wrapped stuff without unwrapping it.

That’s precisely it. The idea goes like this:

1. You take some kind of value and wrap it with some additional information. Just like the value is of a certain kind (eg. an integer or a string), so the additional information is of a certain kind.

   F.ex. that extra information might be a Maybe or an IO.

2. Then you have some operators that allow you to operate on the wrapped data while carrying along that additional information. These operators use the additional information to decide how to change the behaviour of the operation on the wrapped value.

   F.ex., if you add a Maybe Int to a Maybe Int, then the operator will look at the Maybes wrapping the Ints to see if they both have a valid value. If so, it passes the unwrapped Ints to the addition operator and then returns the resulting Int wrapped in a Maybe that says it’s valid; otherwise it just returns a Maybe Int that says it’s empty.

But the example is what happens for a Maybe. If the extra information was an IO, then that special operator defined for IOs would be called instead, and it could do something totally different before performing the addition. (OK, adding two IO Ints together is probably nonsensical – I’m not sure yet.)

Basically, "monad" roughly means "pattern". But instead of a book full of informally explained and specifically named Patterns, you now have a language construct – syntax and all – that allows you to declare a pattern as a thing in your program. (The imprecision here is all the patterns have to follow a particular form, so it’s not quite patterns. But I think that’s the closest term that most people know.)

And that is why people find them so confusing: because they are such a generic concept.

But imagine what this means: instead of having to read the Gang of Four book and memorise the construction of all the patterns, you just write code that implements these patterns in an agnostic, generic way once and then you are done! You can then reuse this pattern, like Visitor or Strategy or Façade or whatever, by decorating the operations in your code with it without having to implement it over and over!

So that is why people who understand monads find them so useful: it’s not some ivory tower concept that intellectual snobs pride themselves on understanding (OK, that too, of course, teehee), but actually makes code simpler.