`join: P -> `__P__

+In the class handout, we gave the types for `>=>` twice, and once was correct but the other was a typo. The above is the correct typing.
+
+Also, in the handout we called `mid` `ð`. But now we've decided that `mid`
+is better. (Think of it as "m" plus "identity", not as the start of "midway".)
+
The menagerie isn't quite as bewildering as you might suppose. Many of these will
be interdefinable. For example, here is how `mcomp` and `mbind` are related: ```
k <=< j â¡
\a. (j a >>= k)
```

.
-In most cases of interest, instances of these systems of functions will provide
-certain useful guarantees.
+We will move freely back and forth between using `>=>` and using `<=<` (aka `mcomp`), which
+is just `>=>` with its arguments flipped. `<=<` has the virtue that it corresponds more
+closely to the ordinary mathematical symbol `â`. But `>=>` has the virtue
+that its types flow more naturally from left to right.
+
+These functions come together in several systems, and have to be defined in a way that coheres with the other functions in the system:
* ***Mappable*** (in Haskelese, "Functors") At the most general level, box types are *Mappable*
if there is a `map` function defined for that box type with the type given above. This
@@ -130,7 +139,9 @@ has to obey the following Map Laws:
`map (id : Î± -> Î±) = (id : `__Î±__ -> __Î±__)

`map (g â f) = (map g) â (map f)`

- Essentially these say that `map` is a homomorphism from `(Î± -> Î², â, id)` to `(`__Î±__ -> __Î²__, â', id')

, where `â'` and `id'` are `â` and `id` restricted to arguments of type _____

. That might be hard to digest because it's so abstract. Think of the following concrete example: if you take a `Î± list` (that's our __Î±__

), and apply `id` to each of its elements, that's the same as applying `id` to the list itself. That's the first law. And if you apply the composition of functions `g â f` to each of the list's elements, that's the same as first applying `f` to each of the elements, and then going through the elements of the resulting list and applying `g` to each of those elements. That's the second law. These laws obviously hold for our familiar notion of `map` in relation to lists.
+ Essentially these say that `map` is a homomorphism from the algebra of `(universe Î± -> Î², operation â, elsment id)` to that of `(`__Î±__ -> __Î²__, â', id')

, where `â'` and `id'` are `â` and `id` restricted to arguments of type _____

. That might be hard to digest because it's so abstract. Think of the following concrete example: if you take a `Î± list` (that's our __Î±__

), and apply `id` to each of its elements, that's the same as applying `id` to the list itself. That's the first law. And if you apply the composition of functions `g â f` to each of the list's elements, that's the same as first applying `f` to each of the elements, and then going through the elements of the resulting list and applying `g` to each of those elements. That's the second law. These laws obviously hold for our familiar notion of `map` in relation to lists.
+
+ > As mentioned at the top of the page, in Category Theory presentations of monads they usually talk about "endofunctors", which are mappings from a Category to itself. In the uses they make of this notion, the endofunctors combine the role of a box type _____

and of the `map` that goes together with it.
* ***MapNable*** (in Haskelese, "Applicatives") A Mappable box type is *MapNable*
--
2.11.0