Merge branch 'main' into monoid-update-boring-parts

Signed-off-by: Matthijs <[email protected]>

Author: MatthijsBlom

source_md/a-fistful-of-monads.md

@@ -208,7 +208,7 @@ Wow, who would have thought?
 This is what the type class looks like:
 
 ```{.haskell:hs}
-class Monad m where
+class Applicative m => Monad m where
     return :: a -> m a
 
     (>>=) :: m a -> (a -> m b) -> m b
@@ -222,13 +222,6 @@ class Monad m where
 
 ![this is you on monads](assets/images/a-fistful-of-monads/kid.png){.right width=363 height=451}
 
-Let's start with the first line.
-It says `class Monad m where`.
-But wait, didn't we say that monads are just beefed up applicative functors?
-Shouldn't there be a class constraint in there along the lines of `class (Applicative m) => Monad m where` so that a type has to be an applicative functor first before it can be made a monad?
-Well, there should, but when Haskell was made, it hadn't occurred to people that applicative functors are a good fit for Haskell so they weren't in there.
-But rest assured, every monad is an applicative functor, even if the `Monad` class declaration doesn't say so.
-
 The first function that the `Monad` type class defines is `return`.
 It's the same as `pure`, only with a different name.
 Its type is `(Monad m) => a -> m a`.

source_md/for-a-few-monads-more.md

@@ -1175,7 +1175,7 @@ Finally, we introduced monads as improved applicative functors, which added the
 
 So every monad is an applicative functor and every applicative functor is a functor.
 The `Applicative` type class has a class constraint such that our type has to be an instance of `Functor` before we can make it an instance of `Applicative`.
-But even though `Monad` should have the same constraint for `Applicative`, as every monad is an applicative functor, it doesn't, because the `Monad` type class was introduced to Haskell way before `Applicative`.
+Likewise, the `Monad` class enforces an `Applicative` constraint, ensuring every monad instance is strictly built upon an applicative functor instance.
 
 But even though every monad is a functor, we don't have to rely on it having a `Functor` instance because of the `liftM` function.
 `liftM` takes a function and a monadic value and maps it over the monadic value.

source_md/functors-applicative-functors-and-monoids.md

@@ -130,7 +130,7 @@ From the definition of sections, `(-4)` would result in a function that takes a
 However, for convenience, `(-4)` means minus four.
 So if you want to make a function that subtracts 4 from the number it gets as a parameter, partially apply the `subtract` function like so: `(subtract 4)`.
 
-What happens if we try to just do `multThree 3 4` in GHCi instead of binding it to a name with a *let* or passing it to another function?
+What happens if we try to just do `multThree 3 4` in GHCi instead of binding it to a name with a `let` or passing it to another function?
 
 ```{.haskell:hs}
 ghci> multThree 3 4
@@ -495,7 +495,7 @@ To make a lambda, we write a `\` (because it kind of looks like the greek letter
 After that comes a `->` and then the function body.
 We usually surround them by parentheses, because otherwise they extend all the way to the right.
 
-If you look about 5 inches up, you'll see that we used a *where* binding in our `numLongChains` function to make the `isLong` function for the sole purpose of passing it to `filter`.
+If you look about 5 inches up, you'll see that we used a `where` binding in our `numLongChains` function to make the `isLong` function for the sole purpose of passing it to `filter`.
 Well, instead of doing that, we can use a lambda:
 
 ```{.haskell:hs}
@@ -960,7 +960,7 @@ Many times, a point free style is more readable and concise, because it makes yo
 You can take simple functions and use composition as glue to form more complex functions.
 However, many times, writing a function in point free style can be less readable if a function is too complex.
 That's why making long chains of function composition is discouraged, although I plead guilty of sometimes being too composition-happy.
-The preferred style is to use *let* bindings to give labels to intermediary results or split the problem into sub-problems and then put it together so that the function makes sense to someone reading it instead of just making a huge composition chain.
+The preferred style is to use `let` bindings to give labels to intermediary results or split the problem into sub-problems and then put it together so that the function makes sense to someone reading it instead of just making a huge composition chain.
 
 In the section about maps and filters, we solved a problem of finding the sum of all odd squares that are smaller than 10,000.
 Here's what the solution looks like when put into a function.