Merge pull request #572 from typelevel/markdown-tweaks

Clean up some markdown issues

Author: valencik

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
 

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

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
+

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:

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

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.

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.
 

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

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

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