From 8ca709089d6e40147050a1a0d033d27cffc2c3b9 Mon Sep 17 00:00:00 2001 From: Kalle Jepsen Date: Fri, 10 Aug 2018 08:33:43 +0200 Subject: [PATCH 1/2] Fix some minor typos --- 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 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/src/main/tut/typeclasses/contravariant.md b/docs/src/main/tut/typeclasses/contravariant.md index 9c32b1a0b8..2ccfe32856 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 11b2459785..74da4741e4 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 cb5a0bae36..763c9ac17c 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 8157a440a1..e7a83b9a01 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 03d0910a05..d5228297be 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 { From 234a776df6afc47755d4b0517005c8a4bbff41a6 Mon Sep 17 00:00:00 2001 From: Kalle Jepsen Date: Fri, 10 Aug 2018 08:34:32 +0200 Subject: [PATCH 2/2] 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 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/src/main/resources/microsite/data/menu.yml b/docs/src/main/resources/microsite/data/menu.yml index ec127708fc..a9a705df26 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