Make changes suggested by Ryan

content/blog/00_compiler_intro.md

@@ -54,7 +54,7 @@ an alternative way of representing the program that isn't machine code.
 In some compilers, the stages of parsing and analysis can overlap.
 In short, just like the pirate's code, it's more of a guideline than a rule.
 
-#### What we'll cover
+#### What we will cover
 We'll go through the stages of a compiler, starting from scratch
 and building up our project. We'll cover:
 
@@ -128,7 +128,7 @@ constructed from an integer and another list (as defined in our `data` example),
 return the integer".
 
 That's it for the introduction! In the next post, we'll cover tokenizng, which is
-the first step in coverting source code into an executable program.
+the first step in converting source code into an executable program.
 
 ### Navigation
 Here are the posts that I've written so far for this series:
@@ -136,3 +136,4 @@ Here are the posts that I've written so far for this series:
 * [Tokenizing]({{< relref "01_compiler_tokenizing.md" >}})
 * [Parsing]({{< relref "02_compiler_parsing.md" >}})
 * [Typechecking]({{< relref "03_compiler_typechecking.md" >}})
+* [Small Improvements]({{< relref "04_compiler_improvements.md" >}})

content/blog/01_compiler_tokenizing.md

@@ -142,7 +142,7 @@ C++ code that should be executed when the regular expression is matched.
 The first token: whitespace. This includes the space character,
 and the newline character. We ignore it, so its rule is empty. After that,
 we have the regular expressions for the tokens we've talked about. For each, I just
-print a description of the token that matched. This will change we we hook this up to
+print a description of the token that matched. This will change when we hook this up to
 a parser, but for now, this works fine. Notice that the variable `yytext` contains
 the string matched by our regular expression. This variable is set by the code flex
 generates, and we can use it to get the extract text that matched a regex. This is
@@ -170,3 +170,6 @@ TIMES
 NUMBER: 6
 ```
 Hooray! We have tokenizing.
+
+With our text neatly divided into meaningful chunks, we
+can continue on to [Part 2 - Parsing]({{< relref "02_compiler_parsing.md" >}}).

content/blog/02_compiler_parsing.md

@@ -289,5 +289,6 @@ wrong:
 }{
 ```
 We are told an error occured. Excellent! We're not really sure what our tree looks like, though.
-We just know there's __stuff__ in the list of definitions. We will revisit our trees
-in the next post, adding code to print them and to verify that our programs make some sense.
+We just know there's __stuff__ in the list of definitions. Having read our source code into
+a structure we're more equipped to handle, we can now try to verify that the code
+makes sense in [Part 3 - Type Checking]({{< relref "03_compiler_typechecking.md" >}})

content/blog/03_compiler_typechecking.md

@@ -604,3 +604,6 @@ as well as these two:
 
 All of our examples print the number of declarations in the program,
 which means they don't throw 0. And so, we have typechecking!
+Before we look at how we will execute our source code,
+we will slow down and make quality of life improvements
+in our codebase in [Part 4 - Small Improvements]({{< relref "04_compiler_improvements.md" >}})