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

@@ -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
 -------------------

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