diff --git a/collections/_posts/2013-07-07-generic-numeric-programming.md b/collections/_posts/2013-07-07-generic-numeric-programming.md index 84f74ca..050891c 100644 --- a/collections/_posts/2013-07-07-generic-numeric-programming.md +++ b/collections/_posts/2013-07-07-generic-numeric-programming.md @@ -352,16 +352,16 @@ trait Fractional[A] extends Integral[A] with Field[A] with NRoot[A] Spire also adds many new useful number types. Here's an incomplete list: -- **spire.math.Rational** is a fast, exact number type for working with +- `spire.math.Rational` is a fast, exact number type for working with rational numbers, -- **spire.math.Complex[A]** is a parametric number type for complex numbers, -- **spire.math.Number** is a boxed number type that strives for flexibility +- `spire.math.Complex[A]` is a parametric number type for complex numbers, +- `spire.math.Number` is a boxed number type that strives for flexibility of use, -- **spire.math.Interval** is a number type for interval arithmetic, -- **spire.math.Real** is a number type for exact geometric computation that +- `spire.math.Interval` is a number type for interval arithmetic, +- `spire.math.Real` is a number type for exact geometric computation that provides exact n-roots, as well as exact division, -- **spire.math.{UByte,UShort,UInt,ULong}** unsigned integer types, and -- **spire.math.Natural** an arbitrary precision unsigned integer type. +- `spire.math.{UByte,UShort,UInt,ULong}` unsigned integer types, and +- `spire.math.Natural` an arbitrary precision unsigned integer type. ### Better Readability diff --git a/collections/_posts/2013-09-11-using-scalaz-Unapply.md b/collections/_posts/2013-09-11-using-scalaz-Unapply.md index b9af96d..4f18260 100644 --- a/collections/_posts/2013-09-11-using-scalaz-Unapply.md +++ b/collections/_posts/2013-09-11-using-scalaz-Unapply.md @@ -212,7 +212,7 @@ types are equal, and is much more powerful than scala-library's own `=:=`. We're using the core Leibniz operator, `subst`, directly to prove that, *as a consequence of that type equality*, `List[FA] === List[U.M[U.A]]` is *also* a type equality, and that therefore this -[constant-time] coercion is valid. This lifting is applicable in all +(constant-time) coercion is valid. This lifting is applicable in all contexts, not just covariant ones like `List`'s. Take a look at [the full API](https://github.com/scalaz/scalaz/blob/v7.0.3/core/src/main/scala/scalaz/Leibniz.scala) for more, though you'll typically just need to come up with the right diff --git a/collections/_posts/2013-10-18-treelog.md b/collections/_posts/2013-10-18-treelog.md index 152fca0..e3af52e 100644 --- a/collections/_posts/2013-10-18-treelog.md +++ b/collections/_posts/2013-10-18-treelog.md @@ -192,3 +192,6 @@ Further Reading - [Monad Transformers in Scala](http://debasishg.blogspot.co.uk/2011/07/monad-transformers-in-scala.html) - [Monad Transformers in the Wild](http://www.slideshare.net/StackMob/monad-transformers-in-the-wild) + +[README]: https://github.com/lancewalton/treelog/blob/main/README.md + diff --git a/collections/_posts/2015-07-13-type-members-parameters.md b/collections/_posts/2015-07-13-type-members-parameters.md index 168d259..e0e4822 100644 --- a/collections/_posts/2015-07-13-type-members-parameters.md +++ b/collections/_posts/2015-07-13-type-members-parameters.md @@ -1,6 +1,6 @@ --- layout: post -title: Type members are [almost] type parameters +title: Type members are almost type parameters category: technical meta: diff --git a/collections/_posts/2015-07-23-type-projection.md b/collections/_posts/2015-07-23-type-projection.md index 8662c6f..25a0784 100644 --- a/collections/_posts/2015-07-23-type-projection.md +++ b/collections/_posts/2015-07-23-type-projection.md @@ -151,7 +151,7 @@ even Java manages the task. But it just seems *odder* that merely calling a method can create a whole refinement `{...}` raincloud, from scratch, filling in the blanks with sensible types along the way. -It’s completely sound, though. An `StSource` [that exists as a value] +It’s completely sound, though. An `StSource` (that exists as a value) *must* have an `S`, even if we existentialized it away. So, as with `_`s, let’s just give it a name to pass as the inferred type parameter. It makes a whole lot more sense than supposing diff --git a/collections/_posts/2015-07-30-values-never-change-types.md b/collections/_posts/2015-07-30-values-never-change-types.md index 4b498b4..60f843d 100644 --- a/collections/_posts/2015-07-30-values-never-change-types.md +++ b/collections/_posts/2015-07-30-values-never-change-types.md @@ -122,7 +122,7 @@ didn’t work, but if we took that `xs` and passed it to a type-parameterized version, everything worked fine. Why is that? If you have a *mutable* variable of an existential type, the -existentialized part of the type may have different [type] values at +existentialized part of the type may have different (type) values at different parts of the program. Let’s use [the `StSource` from the projection post]({% post_url 2015-07-23-type-projection %}#a-good-reason-to-use-type-members). Note that the `S` member is existential, because we did not bind it. diff --git a/collections/_posts/2015-08-06-machinist.md b/collections/_posts/2015-08-06-machinist.md index ca1dedc..01c7e9f 100644 --- a/collections/_posts/2015-08-06-machinist.md +++ b/collections/_posts/2015-08-06-machinist.md @@ -22,7 +22,7 @@ Introduction > Is it correct, that this stuff is completely obsolete now due to > value classes or are there still some use cases? An example of using -> value class for zero-cost implicit enrichment: [...] +> value class for zero-cost implicit enrichment: (...) The short answer is that value classes existed before the Machinist macros were implemented, and they do not solve the same problem Machinist solves. diff --git a/collections/_posts/2016-08-21-hkts-moving-forward.md b/collections/_posts/2016-08-21-hkts-moving-forward.md index fa4b2a6..ec03c37 100644 --- a/collections/_posts/2016-08-21-hkts-moving-forward.md +++ b/collections/_posts/2016-08-21-hkts-moving-forward.md @@ -12,13 +12,13 @@ meta: As its opening sentence reminds the reader—a point often missed by many reviewers—the book [*Functional Programming in Scala*](https://www.manning.com/books/functional-programming-in-scala) -is not a book about Scala. This [wise] choice occasionally manifests +is not a book about Scala. This (wise) choice occasionally manifests in peculiar ways. For example, you can go quite far into the book implementing its exercises in languages with simpler type systems. Chapters 1–8 and 10 port quite readily to -[Java [8]](https://github.com/sbordet/fpinscala-jdk8) and C#. So +[Java 8](https://github.com/sbordet/fpinscala-jdk8) and C#. So *Functional Programming in Scala* can be a very fine resource for learning some typed functional programming, even if such languages are all you have to work with. Within these chapters, you can remain diff --git a/collections/_posts/2017-03-01-four-ways-to-escape-a-cake.md b/collections/_posts/2017-03-01-four-ways-to-escape-a-cake.md index f624f71..a0d058c 100644 --- a/collections/_posts/2017-03-01-four-ways-to-escape-a-cake.md +++ b/collections/_posts/2017-03-01-four-ways-to-escape-a-cake.md @@ -214,7 +214,7 @@ There’s a hint in that we had to write `val u`, not `u`, nor `private val u`, in order for the `implicit class` itself to compile. This signature tells us that there’s an *argument* of type `LittleUniverse`, and a *member* `u: LittleUniverse`. However, whereas -with the function examples above, we [and the compiler] could trust +with the function examples above, we (and the compiler) could trust that they’re one and the same, we have no such guarantee here. So we don’t know that an `lu.Needle` is a `u.Needle`. We didn’t get far enough, but we don’t know that a `u.Needle` is an `lu.Needle`, either. @@ -420,7 +420,7 @@ Let’s walk through it one more time. 1. `n: U#Needle`. 2. `h.iter` expects a `u.type#Needle` for all `val u: U`. 3. **Suppose that we constrain `U` to be a singleton type**: - 1. [The existential] `u.type = U`, by singleton equivalence. + 1. (The existential) `u.type = U`, by singleton equivalence. 2. By `#` left side equivalence, `h.iter` expects a `U#Needle`. The existential variable complicates things, but the rule is sound. @@ -540,7 +540,7 @@ First, covariant: Secondly, contravariant. We’re going to have to make a best guess here, because it’s not entirely clear to me what’s going on. -1. Since [existential] path `u` has a singleton type `U` (if we define +1. Since (existential) path `u` has a singleton type `U` (if we define “has a singleton type” as “having a type *X* such that *X*` <: Singleton`”), so `u.type = U` by the singleton equivalence. 2. Since equivalence implies conformance, according to the first diff --git a/collections/_posts/2017-12-20-who-implements-typeclass.md b/collections/_posts/2017-12-20-who-implements-typeclass.md index 8acc213..5aeb84a 100644 --- a/collections/_posts/2017-12-20-who-implements-typeclass.md +++ b/collections/_posts/2017-12-20-who-implements-typeclass.md @@ -392,7 +392,7 @@ because names with variable type patterns. 1. You can’t use variable type patterns with the structural “ADT-style” patterns; you must instead use inelegant and - inconvenient [non-variable] type patterns. (This may be + inconvenient (non-variable) type patterns. (This may be [improved in Typelevel Scala 4](https://github.com/typelevel/scala/blob/typelevel-readme/notes/typelevel-4.md#type-arguments-on-patterns-pull5774-paulp).) Yet this remains entirely up to shortcomings in the current pattern diff --git a/collections/_posts/2018-07-12-testing-in-the-wild.md b/collections/_posts/2018-07-12-testing-in-the-wild.md index 9300cce..111273d 100644 --- a/collections/_posts/2018-07-12-testing-in-the-wild.md +++ b/collections/_posts/2018-07-12-testing-in-the-wild.md @@ -216,6 +216,7 @@ I needed to change the expected values? To this end I added a "line number" colu Actually I even enhanced the display of actual/expected values by coloring them in green or red in the console, using one of specs2 helper classes `org.specs2.text.AnsiColors`: + ```scala import org.specs2.text.AnsiColors