Fix minor typos in typeclasses docs (#2377)

* Fix some minor typos

* Move section SemigroupK before MonoidK

Analogous to the introduction of Semigroup and Monoid, since SemigroupK
is weaker than MonoidK. Also the SemigroupK section introduces the
notion of kinds, knowledge of which seems to be assumed in the MonoidK
section.

docs/src/main/resources/microsite/data/menu.yml

@@ -92,14 +92,14 @@ options:
     url: typeclasses/parallel.html
     menu_type: typeclasses
 
-  - title: MonoidK
-    url: typeclasses/monoidk.html
-    menu_type: typeclasses
-
   - title: SemigroupK
     url: typeclasses/semigroupk.html
     menu_type: typeclasses
 
+  - title: MonoidK
+    url: typeclasses/monoidk.html
+    menu_type: typeclasses
+
   - title: Show
     url: typeclasses/show.html
     menu_type: typeclasses
@@ -167,7 +167,7 @@ options:
   - title: Nested
     url: datatypes/nested.html
     menu_type: data
-    
+
   - title: NonEmptyList
     url: datatypes/nel.html
     menu_type: data

docs/src/main/tut/typeclasses/contravariant.md

@@ -24,7 +24,7 @@ Examples of `Contravariant` instances are [`Show`](show.html) and `scala.math.Or
 
 ## Contravariant instance for Show.
 
-Say we have class `Money` with a `Show` instance, and `Salary` class. 
+Say we have a class `Money` with a `Show` instance, and a `Salary` class:
 
 ```tut:silent
 import cats._
@@ -37,10 +37,10 @@ case class Salary(size: Money)
 implicit val showMoney: Show[Money] = Show.show(m => s"$$${m.amount}")
 ```
 
-If we want to show a `Salary` instance, we can just convert it to a `Money` instance and show it instead.
+If we want to show a `Salary` instance, we can just convert it to a `Money` instance and show that instead.
 
 Let's use `Show`'s `Contravariant`:
-  
+
 ```tut:book
 implicit val showSalary: Show[Salary] = showMoney.contramap(_.size)
 
@@ -49,9 +49,9 @@ Salary(Money(1000)).show
 
 ## Contravariant instance for scala.math.Ordering.
 
-`Show` example is trivial and quite far-fetched, let's see how `Contravariant` can help with orderings.
+The `Show` example is trivial and quite far-fetched, let's see how `Contravariant` can help with orderings.
 
-`scala.math.Ordering` type class defines comparison operations, e.g. `compare`:
+The `scala.math.Ordering` type class defines comparison operations, e.g. `compare`:
 
 ```tut:book
 Ordering.Int.compare(2, 1)
@@ -66,7 +66,7 @@ def by[T, S](f: T => S)(implicit ord: Ordering[S]): Ordering[T]
 
 In fact, it is just `contramap`, defined in a slightly different way! We supply `T => S` to receive `F[S] => F[T]` back.
 
-So let's use it in our advantage and get `Ordering[Money]` for free: 
+So let's use it to our advantage and get `Ordering[Money]` for free:
 
 ```tut:book
 // we need this for `<` to work

docs/src/main/tut/typeclasses/functor.md

@@ -57,7 +57,7 @@ function to a single effectful value without needing to "leave" the effect.
 
 ## Functors compose
 
-If you're ever found yourself working with nested data types such as `Option[List[A]]` or a
+If you've ever found yourself working with nested data types such as `Option[List[A]]` or
 `List[Either[String, Future[A]]]` and tried to `map` over it, you've most likely found yourself doing something
 like `_.map(_.map(_.map(f)))`. As it turns out, `Functor`s compose, which means if `F` and `G` have
 `Functor` instances, then so does `F[G[_]]`.
@@ -106,7 +106,7 @@ nested.map(_ + 1)
 ```
 
 The `Nested` approach, being a distinct type from its constituents, will resolve the usual way modulo
-possible [SI-2712][si2712] issues (which can be addressed through [partial unification][partial-unification]), 
+possible [SI-2712][si2712] issues (which can be addressed through [partial unification][partial-unification]),
 but requires syntactic and runtime overhead from wrapping and unwrapping.
 
 [partial-unification]: https://github.com/fiadliel/sbt-partial-unification "A sbt plugin for enabling partial unification"

docs/src/main/tut/typeclasses/semigroupk.md

@@ -39,7 +39,7 @@ types, a `Semigroup[Option[A]]` knows the concrete type of `A` and will use
 `Semigroup[A].combine` to combine the inner `A`s. Consequently,
 `Semigroup[Option[A]].combine` requires an implicit `Semigroup[A]`.
 
-In contrast, since `SemigroupK[Option]` operates on `Option` where
+In contrast, `SemigroupK[Option]` operates on `Option` where
 the inner type is not fully specified and can be anything (i.e. is
 "universally quantified"). Thus, we cannot know how to `combine`
 two of them. Therefore, in the case of `Option` the

docs/src/main/tut/typeclasses/show.md

@@ -15,7 +15,7 @@ def show(a: A): String
 ```
 
 You might be wondering why you would want to use this, considering `toString` already serves the same purpose and case classes already provide sensible implementations for `toString`.
-The difference, is that `toString` is defined on `Any`(Java's `Object`) and can therefore be called on anything, not just case classes.
+The difference is that `toString` is defined on `Any`(Java's `Object`) and can therefore be called on anything, not just case classes.
 Most often, this is unwanted behaviour, as the standard implementation of `toString` on non case classes is mostly gibberish.
 Consider the following example:
 

docs/src/main/tut/typeclasses/traverse.md

@@ -23,7 +23,7 @@ def traverse[F[_]: Applicative, A, B](as: List[A])(f: A => F[B]): F[List[B]] =
 ```
 
 Here `traverse` still has knowledge of `List`, but we could just as easily use
-`Vector` or similar data type. Another example is a binary tree:
+`Vector` or some similar data type. Another example is a binary tree:
 
 ```tut:book:silent
 object tree {