From 0100939c64423488032f18e3d74fcc16ddd6cef7 Mon Sep 17 00:00:00 2001 From: ksonj Date: Tue, 14 Aug 2018 15:19:30 +0200 Subject: [PATCH] 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 | 10 +++++----- docs/src/main/tut/typeclasses/contravariant.md | 12 ++++++------ docs/src/main/tut/typeclasses/functor.md | 4 ++-- docs/src/main/tut/typeclasses/semigroupk.md | 2 +- docs/src/main/tut/typeclasses/show.md | 2 +- docs/src/main/tut/typeclasses/traverse.md | 2 +- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/src/main/resources/microsite/data/menu.yml b/docs/src/main/resources/microsite/data/menu.yml index ec127708fc4..a9a705df265 100644 --- a/docs/src/main/resources/microsite/data/menu.yml +++ b/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 diff --git a/docs/src/main/tut/typeclasses/contravariant.md b/docs/src/main/tut/typeclasses/contravariant.md index 9c32b1a0b87..2ccfe32856b 100644 --- a/docs/src/main/tut/typeclasses/contravariant.md +++ b/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 diff --git a/docs/src/main/tut/typeclasses/functor.md b/docs/src/main/tut/typeclasses/functor.md index 11b2459785e..74da4741e48 100644 --- a/docs/src/main/tut/typeclasses/functor.md +++ b/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" diff --git a/docs/src/main/tut/typeclasses/semigroupk.md b/docs/src/main/tut/typeclasses/semigroupk.md index cb5a0bae367..763c9ac17c5 100644 --- a/docs/src/main/tut/typeclasses/semigroupk.md +++ b/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 diff --git a/docs/src/main/tut/typeclasses/show.md b/docs/src/main/tut/typeclasses/show.md index 8157a440a10..e7a83b9a013 100644 --- a/docs/src/main/tut/typeclasses/show.md +++ b/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: diff --git a/docs/src/main/tut/typeclasses/traverse.md b/docs/src/main/tut/typeclasses/traverse.md index 03d0910a052..d5228297be6 100644 --- a/docs/src/main/tut/typeclasses/traverse.md +++ b/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 {