[1, 2, 3] :: [Int]
[1, 2, 3] :: [Int]
| | | (+ 1)
v v v
[2, 3, 4] :: [Int]
[ 1, 2, 3 ] :: [Int]
| | | (show)
v v v
["1", "2", "3"] :: [String]
[ 1, 2, 3 ] :: [Int]
| | | (show)
v v v
[['1'], ['2'], ['3']] :: [[Char]]
[['1'], ['2'], ['3']] :: [[Char]]
| | | (concat)
v v v
[ '1', '2', '3' ] :: [Char]
[[1,2,3], [4,5,6], [7,8,9]] :: [[Int]]
| | | (concat)
v v v
[1, 2, 3, 4, 5, 6, 7, 8, 9] :: [Int]
1. Something is a "Functor" if you know how to call `map` on it, nothing more. "I can take a box of things and turn it into a box of other things, 1-to-1". On lists, for example, this is just `map` itself
2. Something is an "Applicative" if you know how to call `map` on it, but also know how to take a non-boxed value and put it in a box, and also know how to combine boxes in order
3. Something is a "Monad" if you know how to do all of the above, but also know how to call `flatMap` on it, nothing more. "I can take a box of things, turn each thing into a new box, and then combine them all in order". On lists, for example this is just `concatMap`
1. Monads themselves are neither necessary nor sufficient to perform side effects in Haskell; they don't directly enable the effects, but they *do* help place guardrails on the actual unsafe, low-level code which *can* perform the effects, safely and in an ergonomic and composable way
2. Yes, "Monad" is just a name for a recurring way to approach a problem. Like in most math and programming, a certain repeating pattern was noticed, and given a name. Because of the math origin of the term, you get "Monad" instead of "flat-mappable"
3. Like any other tool, you reach for a monad when you have a monad-shaped problem. They're just one (powerful) tool for solving certain problems
One way to represent side effects in a purely functional language is to model them as if they aren't side effects, by representing them as state changes in the "outside world". You don't need to grok the specifics of this, but the definition of the `IO` monad is:
i.e., it's a "pure" transformation of the "real world".
This allows you to define a "box" called `IO` that represents a computation that can perform a side-effect (by affecting the "real world"), then returning a value.
The real trick to this is that the "box" is entirely opaque to you: unlike a list or a `Maybe` where you know how to reach in and pull values _out_ (e.g., `head`, `last`, `fromJust`, etc.), `IO` doesn't allow you to do this*. Once you have something inside of an `IO` box, it's stuck there.
This means that you can separate the "impure" world from the "pure" world: you can't perform side effects arbitrarily — you're can only do so in an `IO` context that's intentionally "viral".
The functor/applicative/monad rules just make `IO` easier to use and consume:
This is just one way to represent side effects, and the monad rules are only really needed to make this representation ergonomic to actually use.
(*There is technically a way to "escape" the `IO` monad called `unsafePerformIO`, but you basically never need to use this. If you find yourself reaching for it, don't.)