Fix minor typos in typeclasses docs

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 {