From 4002f4fa2046973ac8e26dac33659411870ffa06 Mon Sep 17 00:00:00 2001 From: Andrew Valencik Date: Sat, 31 Jan 2026 14:16:37 -0500 Subject: [PATCH 1/2] Clean up some markdown issues --- .../2013-07-07-generic-numeric-programming.md | 14 +++++++------- .../_posts/2013-09-11-using-scalaz-Unapply.md | 2 +- collections/_posts/2013-10-18-treelog.md | 4 ++-- .../_posts/2015-07-13-type-members-parameters.md | 2 +- collections/_posts/2015-07-23-type-projection.md | 2 +- .../_posts/2015-07-30-values-never-change-types.md | 2 +- collections/_posts/2015-08-06-machinist.md | 2 +- .../_posts/2016-08-21-hkts-moving-forward.md | 4 ++-- .../2017-03-01-four-ways-to-escape-a-cake.md | 6 +++--- .../_posts/2017-12-20-who-implements-typeclass.md | 2 +- .../_posts/2018-07-12-testing-in-the-wild.md | 1 + 11 files changed, 21 insertions(+), 20 deletions(-) diff --git a/collections/_posts/2013-07-07-generic-numeric-programming.md b/collections/_posts/2013-07-07-generic-numeric-programming.md index 84f74ca0..050891c5 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 b9af96df..4f182602 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 152fca00..6f9c1734 100644 --- a/collections/_posts/2013-10-18-treelog.md +++ b/collections/_posts/2013-10-18-treelog.md @@ -23,7 +23,7 @@ There are a number of problems with this approach: Treelog resolves these issues by making the log itself a tree, reflecting the computational tree it logs, and uses techniques described in the [Typeclassopedia](http://www.haskell.org/wikiupload/e/e9/Typeclassopedia.pdf) to bring logging closer to the computation: the `Writer` Monad, a Monad Transformer, and a cunning Monoid. -Note that this post is a more technical description of how Treelog was written. For a quick introduction of use please refer to the [README]. +Note that this post is a more technical description of how Treelog was written. For a quick introduction of use please refer to the README. I will also refer you to Eugene Yokota's [excellent Scalaz tutorial](http://eed3si9n.com/learning-scalaz/) to study the details of Scalaz where appropriate. Logging with Treelog @@ -87,7 +87,7 @@ Syntactic Sugar Treelog makes use of some syntactic sugar inspired by [Tony Morris's post](http://blog.tmorris.net/posts/the-writer-monad-using-scala-example/) on `Writer`. In the example above, `~>` is a method on an implicitly constructed class which takes any value `x: T` and returns a `DescribedComputation[T]`, representing the value `x` and a leaf node containing the description. -There is special support for `Boolean`s, `Option`s, `Either`s and `Traversable`s which you can learn about from the Treelog [README]. +There is special support for `Boolean`s, `Option`s, `Either`s and `Traversable`s which you can learn about from the Treelog README. `Writer` and Monoid ------------------- diff --git a/collections/_posts/2015-07-13-type-members-parameters.md b/collections/_posts/2015-07-13-type-members-parameters.md index 168d2590..e0e4822b 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 8662c6fc..25a07847 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 4b498b48..60f843d2 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 ca1dedc2..01c7e9f2 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 fa4b2a6a..ec03c37c 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 f624f710..a0d058c3 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 8acc2132..5aeb84a4 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 9300cce8..111273d6 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 From 97ad48058c736a4e025b9d01bbd5271c74084d4c Mon Sep 17 00:00:00 2001 From: Arman Bilge Date: Sat, 31 Jan 2026 11:28:56 -0800 Subject: [PATCH 2/2] Fix link to TreeLog README --- collections/_posts/2013-10-18-treelog.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/collections/_posts/2013-10-18-treelog.md b/collections/_posts/2013-10-18-treelog.md index 6f9c1734..e3af52e8 100644 --- a/collections/_posts/2013-10-18-treelog.md +++ b/collections/_posts/2013-10-18-treelog.md @@ -23,7 +23,7 @@ There are a number of problems with this approach: Treelog resolves these issues by making the log itself a tree, reflecting the computational tree it logs, and uses techniques described in the [Typeclassopedia](http://www.haskell.org/wikiupload/e/e9/Typeclassopedia.pdf) to bring logging closer to the computation: the `Writer` Monad, a Monad Transformer, and a cunning Monoid. -Note that this post is a more technical description of how Treelog was written. For a quick introduction of use please refer to the README. +Note that this post is a more technical description of how Treelog was written. For a quick introduction of use please refer to the [README]. I will also refer you to Eugene Yokota's [excellent Scalaz tutorial](http://eed3si9n.com/learning-scalaz/) to study the details of Scalaz where appropriate. Logging with Treelog @@ -87,7 +87,7 @@ Syntactic Sugar Treelog makes use of some syntactic sugar inspired by [Tony Morris's post](http://blog.tmorris.net/posts/the-writer-monad-using-scala-example/) on `Writer`. In the example above, `~>` is a method on an implicitly constructed class which takes any value `x: T` and returns a `DescribedComputation[T]`, representing the value `x` and a leaf node containing the description. -There is special support for `Boolean`s, `Option`s, `Either`s and `Traversable`s which you can learn about from the Treelog README. +There is special support for `Boolean`s, `Option`s, `Either`s and `Traversable`s which you can learn about from the Treelog [README]. `Writer` and Monoid ------------------- @@ -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 +