From e3fd13c0c1e21c96edd010d7884a2bfeba3b0e03 Mon Sep 17 00:00:00 2001
From: Danila Fedorin <danila.fedorin@gmail.com>
Date: Wed, 4 Sep 2019 01:31:31 -0700
Subject: [PATCH] Remove TODOS from part 5 of compiler series

---
 content/blog/05_compiler_execution.md | 34 +++++++++++++++++++++++----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/content/blog/05_compiler_execution.md b/content/blog/05_compiler_execution.md
index 5b4bc1d..3e1a868 100644
--- a/content/blog/05_compiler_execution.md
+++ b/content/blog/05_compiler_execution.md
@@ -272,8 +272,29 @@ the thing we apply it to. We then create a new node on the heap
 that is an `NApp` node, with its two children being the nodes we popped off.
 Finally, we push it onto the stack.
 
-Let's try use these instructions to get a feel for it.
-{{< todo >}}Add an example, probably without notation.{{< /todo >}}
+Let's try use these instructions to get a feel for it. In
+order to conserve space, let's use \\(\\text{G}\\) for PushGlobal,
+\\(\\text{I}\\) for PushInt, and \\(\\text{A}\\) for PushApp.
+Let's say we want to construct a graph for `double 326`. We'll
+use the instructions \\(\\text{I} \; 326\\), \\(\\text{G} \; \\text{double}\\),
+and \\(\\text{A}\\). Let's watch these instructions play out:
+$$
+\\begin{align}
+[\\text{I} \; 326, \\text{G} \; \text{double}, \\text{A}] & \\quad s \\quad & d \\quad & h \\quad & m[\\text{double} : a\_d] \\\\\\
+[\\text{G} \; \text{double}, \\text{A}] & \\quad a\_1 : s \\quad & d \\quad & h[a\_1 : \\text{NInt} \; 326] \\quad & m[\\text{double} : a\_d] \\\\\\
+[\\text{A}] & \\quad a\_d, a\_1 : s \\quad & d \\quad & h[a\_1 : \\text{NInt} \; 326] \\quad & m[\\text{double} : a\_d] \\\\\\
+[] & \\quad a\_2 : s \\quad & d \\quad & h[\\substack{\\begin{aligned}a\_1 & : \\text{NInt} \; 326 \\\\ a\_2 & : \\text{NApp} \; a\_d \; a\_1 \\end{aligned}}] \\quad & m[\\text{double} : a\_d] \\\\\\
+\\end{align}
+$$
+How did we come up with these instructions? We'll answer this question with
+more generality later, but let's take a look at this particular expression
+right now. We know it's an application, so we'll be using MkApp eventually.
+We also know that MkApp expects two values on top of the stack from
+which to make an application. The node on top has to be the function, and the next
+node is the value to be passed into that function. Since a stack is first-in-last-out,
+for the function (`double`, in our case) to be on top, we need
+to push it last. Thus, we push `double` first, then 326. Finally,
+we call MkApp now that the stack is in the right state.
 
 Having defined instructions to __build__ graphs, it's now time
 to move on to instructions to __reduce__ graphs - after all,
@@ -566,6 +587,9 @@ We can allocate an indirection on the stack, and call Update on it when
 we've constructed a node. While we're constructing the tree, we can
 refer to the indirection when a self-reference is required.
 
-That's it for the instructions. Next up, we have to convert our expression
-trees into such instructions. However, this has already gotten pretty long,
-so we'll do it in the next post.
+That's it for the instructions. Knowing them, however, doesn't
+tell us what to do with our `ast` structs. We'll need to define
+rules to translate trees into these instructions, and I've already
+alluded to this when we went over `double 326`.
+However, this has already gotten pretty long,
+so we'll do it in the next post: (link me!)