diff --git a/javascript/latexContent.js b/javascript/latexContent.js
index 1d9c43cca..31fee02f8 100644
--- a/javascript/latexContent.js
+++ b/javascript/latexContent.js
@@ -121,7 +121,7 @@ export const preamble = `\\documentclass[a4paper, 12pt]{report}
    escapechar=^
 }
 
-\\usepackage{xcolor}
+\\usepackage[svgnames]{xcolor}
 \\definecolor{LeftBarClickable}{RGB}{187, 187, 187}
 
 \\lstdefinestyle{JavaScript}{
diff --git a/javascript/parseXmlLatexSplit.js b/javascript/parseXmlLatexSplit.js
new file mode 100644
index 000000000..59b2845da
--- /dev/null
+++ b/javascript/parseXmlLatexSplit.js
@@ -0,0 +1,386 @@
+import { getChildrenByTagName, ancestorHasTag } from "./utilityFunctions";
+import { checkIndexBadEndWarning } from "./processingFunctions/warnings.js";
+
+import {
+  replaceTagWithSymbol,
+  processEpigraphPdf,
+  processFigurePdf,
+  processFigureEpub,
+  generateImage,
+  processExercisePdf,
+  processExerciseEpub,
+  processFileInput,
+  processSnippetPdf,
+  processSnippetEpub,
+  processTable,
+  recursiveProcessPureText,
+  processList,
+  addName
+} from "./processingFunctions";
+
+const tagsToRemove = new Set([
+  "#comment",
+  "COMMENT",
+  "CHANGE",
+  "EDIT",
+  "EXCLUDE",
+  "HISTORY",
+  "NAME",
+  "INDEX",
+  "CODEINDEX",
+  "EM_NO_INDEX",
+  "ORDER",
+  "SOLUTION",
+  "WEB_ONLY"
+]);
+// SOLUTION tag handled by processSnippet
+
+const ignoreTags = new Set([
+  "CHAPTERCONTENT",
+  "JAVASCRIPT",
+  "SCHEME",
+  "NOBR",
+  "SECTIONCONTENT",
+  "span",
+  "SPLIT",
+  "SPLITINLINE"
+]);
+
+const processTextFunctionsDefaultLatex = {
+  SCHEME: (node, writeTo) => {
+    writeTo.push("{\\color{LightGrey} ");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  JAVASCRIPT: (node, writeTo) => {
+    writeTo.push("{\\color{DarkGrey} ");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  PDF_ONLY: (node, writeTo) => {
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  "#text": (node, writeTo) => {
+    const trimedValue = node.nodeValue
+      .replace(/[\r\n]+/, " ")
+      .replace(/\s+/g, " ")
+      .replace(/\^/g, "^{}")
+      .replace(/%/g, "\\%");
+    if (trimedValue.match(/&(\w|\.)+;/)) {
+      processFileInput(trimedValue.trim(), writeTo);
+    } else {
+      writeTo.push(trimedValue);
+    }
+    // if (!trimedValue.match(/^\s*$/)) {
+    // }
+  },
+
+  ABOUT: (node, writeTo) => {
+    writeTo.push("\\chapter*{");
+    const name = addName(node, writeTo);
+    writeTo.push("\n\\addcontentsline{toc}{chapter}{");
+    writeTo.push(name + "}\n\n");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+  REFERENCES: (node, writeTo) =>
+    processTextFunctionsLatex["ABOUT"](node, writeTo),
+  WEBPREFACE: (node, writeTo) =>
+    processTextFunctionsLatex["ABOUT"](node, writeTo),
+  MATTER: (node, writeTo) => processTextFunctionsLatex["ABOUT"](node, writeTo),
+
+  B: (node, writeTo) => {
+    writeTo.push("\\textbf{");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  BR: (node, writeTo) => {
+    writeTo.push("\n\\noindent ");
+  },
+
+  BLOCKQUOTE: (node, writeTo) => {
+    writeTo.push("\n\\begin{quote}");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("\\end{quote}\n");
+  },
+
+  CHAPTER: (node, writeTo) => {
+    writeTo.push("\\chapter{");
+    addName(node, writeTo);
+    writeTo.push("\\pagestyle{main}\n");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  CITATION: (node, writeTo) => {
+    // Currently just text. Not linked to biblography.
+    const text = node.getElementsByTagName("TEXT")[0];
+    if (text) {
+      recursiveProcessTextLatex(text.firstChild, writeTo);
+    } else {
+      recursiveProcessTextLatex(node.firstChild, writeTo);
+    }
+  },
+
+  EM: (node, writeTo) => processTextFunctionsLatex["em"](node, writeTo),
+  em: (node, writeTo) => {
+    writeTo.push("{\\em ");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  EPIGRAPH: (node, writeTo) => {
+    processEpigraphPdf(node, writeTo);
+  },
+
+  EXERCISE: (node, writeTo) => {
+    processExercisePdf(node, writeTo);
+  },
+
+  FIGURE: (node, writeTo) => {
+    processFigurePdf(node, writeTo);
+  },
+
+  FOOTNOTE: (node, writeTo) => {
+    writeTo.push("\\cprotect\\footnote{");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}\n");
+  },
+
+  H2: (node, writeTo) => {
+    writeTo.push("\n\\subsection*{");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}\n");
+  },
+
+  /*
+  INDEX: (node, writeTo) => {
+    writeTo.push("\\index{");
+    const indexArr = [];
+    const order = getChildrenByTagName(node, "ORDER")[0];
+    if (order) {
+      recursiveProcessTextLatex(order.firstChild, indexArr);
+      indexArr.push("@");
+    }
+    recursiveProcessTextLatex(node.firstChild, indexArr);
+    const indexStr = indexArr.join("").trim();
+
+    // Do error checking
+    checkIndexBadEndWarning(indexStr);
+    writeTo.push(indexStr);
+    writeTo.push("}");
+  },
+    */
+
+  IMAGE: (node, writeTo) => {
+    writeTo.push(
+      "\\begin{figure}[H]\n\\centering" +
+        generateImage(node.getAttribute("src")) +
+        "\n\\end{figure}\n"
+    );
+  },
+
+  LABEL: (node, writeTo) => {
+    writeTo.push("\\label{" + node.getAttribute("NAME") + "}\n");
+  },
+
+  LINK: (node, writeTo) => {
+    writeTo.push("\\href{" + node.getAttribute("address") + "}{");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  LATEX: (node, writeTo) =>
+    processTextFunctionsLatex["LATEXINLINE"](node, writeTo),
+  LATEXINLINE: (node, writeTo) => {
+    recursiveProcessPureText(node.firstChild, writeTo);
+  },
+
+  MATTERSECTION: (node, writeTo) => {
+    writeTo.push("\\section*{");
+    addName(node, writeTo);
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  OL: (node, writeTo) => {
+    writeTo.push("\n\\begin{enumerate}");
+    writeTo.push(ancestorHasTag(node, "EXERCISE") ? "[a.]\n" : "\n");
+    processList(node.firstChild, writeTo);
+    writeTo.push("\\end{enumerate}\n");
+  },
+
+  P: (node, writeTo) => processTextFunctionsLatex["TEXT"](node, writeTo),
+  TEXT: (node, writeTo) => {
+    writeTo.push("\n\n");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("\n");
+  },
+
+  QUOTE: (node, writeTo) => {
+    writeTo.push("\\enquote{");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  REF: (node, writeTo) => {
+    writeTo.push("\\ref{" + node.getAttribute("NAME") + "}");
+  },
+
+  REFERENCE: (node, writeTo) => {
+    // Doesn't do anything special
+    writeTo.push("\n");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("\n");
+  },
+
+  SC: (node, writeTo) => {
+    writeTo.push("{\\scshape ");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+    writeTo.push("}");
+  },
+
+  SECTION: (node, writeTo) => {
+    writeTo.push("\\section{");
+    addName(node, writeTo);
+    writeTo.push("\\pagestyle{section}\n");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  SUBHEADING: (node, writeTo) => {
+    writeTo.push("\\subsubsection{");
+    addName(node, writeTo);
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+  SUBSUBSECTION: (node, writeTo) =>
+    processTextFunctionsLatex["SUBHEADING"](node, writeTo),
+
+  SCHEMEINLINE: (node, writeTo) =>
+    processTextFunctionsLatex["JAVASCRIPTINLINE"](node, writeTo),
+  JAVASCRIPTINLINE: (node, writeTo) => {
+    writeTo.push("{\\lstinline[mathescape=true]$");
+    recursiveProcessPureText(node.firstChild, writeTo, {
+      removeNewline: "all"
+    });
+    writeTo.push("$}");
+  },
+
+  SNIPPET: (node, writeTo) => {
+    processSnippetPdf(node, writeTo);
+  },
+
+  SUBHEADING: (node, writeTo) => {
+    writeTo.push("\\subsubsection{");
+    addName(node, writeTo);
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  SUBINDEX: (node, writeTo) => {
+    // should occur only within INDEX
+    // also should only exist after stuff in the main index
+    writeTo.push("!");
+    const order = getChildrenByTagName(node, "ORDER")[0];
+    if (order) {
+      recursiveProcessTextLatex(order.firstChild, writeTo);
+      writeTo.push("@");
+    }
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  SUBSECTION: (node, writeTo) => {
+    writeTo.push("\\subsection{");
+    addName(node, writeTo);
+    writeTo.push("\\pagestyle{subsection}\n");
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+
+  TABLE: (node, writeTo) => {
+    processTable(node, writeTo);
+  },
+
+  TT: (node, writeTo) => {
+    writeTo.push("\\texttt{");
+    recursiveProcessTextLatex(node.firstChild, writeTo, true);
+    writeTo.push("}");
+  },
+
+  UL: (node, writeTo) => {
+    writeTo.push("\n\\begin{itemize}\n");
+    processList(node.firstChild, writeTo);
+    writeTo.push("\\end{itemize}\n");
+  }
+};
+
+const processTextFunctionsEpub = {
+  EXERCISE: (node, writeTo) => {
+    processExerciseEpub(node, writeTo);
+  },
+  FIGURE: (node, writeTo) => {
+    processFigureEpub(node, writeTo);
+  },
+  SECTION: (node, writeTo) => {
+    writeTo.push("\\section{");
+    addName(node, writeTo);
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+  JAVASCRIPTINLINE: (node, writeTo) => {
+    writeTo.push("{\\lstinline[mathescape=true, language=JavaScript]$");
+    recursiveProcessPureText(node.firstChild, writeTo, {
+      removeNewline: "all"
+    });
+    writeTo.push("$}");
+  },
+  SNIPPET: (node, writeTo) => {
+    processSnippetEpub(node, writeTo);
+  },
+  SUBSECTION: (node, writeTo) => {
+    writeTo.push("\\subsection{");
+    addName(node, writeTo);
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+  SUBHEADING: (node, writeTo) => {
+    writeTo.push("\\paragraph{");
+    addName(node, writeTo);
+    recursiveProcessTextLatex(node.firstChild, writeTo);
+  },
+  SUBSUBSECTION: (node, writeTo) =>
+    processTextFunctionsEpub["SUBHEADING"](node, writeTo)
+};
+
+let processTextFunctionsLatex = processTextFunctionsDefaultLatex;
+
+export const switchParseFunctionsLatex = parseType => {
+  if (parseType == "pdf") {
+    processTextFunctionsLatex = processTextFunctionsDefaultLatex;
+  } else if (parseType == "epub") {
+    console.log("using parsetype epub");
+    processTextFunctionsLatex = {
+      ...processTextFunctionsDefaultLatex,
+      ...processTextFunctionsEpub
+    };
+  }
+};
+
+export const processTextLatex = (node, writeTo) => {
+  const name = node.nodeName;
+  if (processTextFunctionsLatex[name]) {
+    processTextFunctionsLatex[name](node, writeTo);
+    return true;
+  } else {
+    if (replaceTagWithSymbol(node, writeTo) || tagsToRemove.has(name)) {
+      return true;
+    } else if (ignoreTags.has(name)) {
+      recursiveProcessTextLatex(node.firstChild, writeTo);
+      return true;
+    }
+  }
+  console.log("WARNING Unrecognised Tag:\n" + node.toString() + "\n");
+  return false;
+};
+
+export const recursiveProcessTextLatex = (node, writeTo) => {
+  if (!node) return;
+  processTextLatex(node, writeTo);
+  return recursiveProcessTextLatex(node.nextSibling, writeTo);
+};
diff --git a/javascript/processingFunctions/processFigureHtml.js b/javascript/processingFunctions/processFigureHtml.js
index 426fcfd8e..0edc63700 100755
--- a/javascript/processingFunctions/processFigureHtml.js
+++ b/javascript/processingFunctions/processFigureHtml.js
@@ -11,11 +11,24 @@ export const processFigureHtml = (node, writeTo) => {
   if (!src && node.getElementsByTagName("FIGURE")[0]) {
     src = node.getElementsByTagName("FIGURE")[0].getAttribute("src");
   }
+
+  let scale_factor = "scale_factor_0";
+  if (
+    !node.getAttribute("scale_factor") &&
+    node.getElementsByTagName("FIGURE")[0]
+  ) {
+    scale_factor =
+      "scale_factor_" +
+      node.getElementsByTagName("FIGURE")[0].getAttribute("scale_factor");
+  } else {
+    scale_factor = "scale_factor_" + node.getAttribute("scale_factor");
+  }
+
   const label = node.getElementsByTagName("LABEL")[0];
 
   if (src && !label) {
     writeTo.push(`
-        <img src="${toIndexFolder}${src}">
+        <img class="${scale_factor}" src="${toIndexFolder}${src}">
       `);
     return;
   } else if (!src) {
@@ -24,7 +37,9 @@ export const processFigureHtml = (node, writeTo) => {
     const images = node.getElementsByTagName("IMAGE");
     for (let i = 0; i < images.length; i++) {
       writeTo.push(`
-      <img src="${toIndexFolder}${images[i].getAttribute("src")}">
+      <img class="${scale_factor}" src="${toIndexFolder}${images[
+        i
+      ].getAttribute("src")}">
       `);
     }
   }
@@ -39,7 +54,7 @@ export const processFigureHtml = (node, writeTo) => {
   if (src && label) {
     writeTo.push(`
     <FIGURE>
-      <img id="fig_${displayName}" src="${toIndexFolder}${src}">`);
+      <img class="${scale_factor}" id="fig_${displayName}" src="${toIndexFolder}${src}">`);
   }
 
   const snippet = node.getElementsByTagName("SNIPPET")[0];
diff --git a/static/assets/stylesheet.css b/static/assets/stylesheet.css
index 706e90fe5..5c86006bc 100644
--- a/static/assets/stylesheet.css
+++ b/static/assets/stylesheet.css
@@ -74,6 +74,10 @@ figure > div.snippet {
   text-align: left;
 }
 
+figure > pre {
+  text-align: left;
+}
+
 caption {
   margin: 20px auto !important;
   text-weight: bold;
@@ -84,10 +88,26 @@ h2 {
   font-size: 18pt !important;
 }
 
-img {
+img.scale_factor_0 {
   margin: 10px 5px;
 }
 
+img.scale_factor_1 {
+  margin: 10px 10%;
+}
+img.scale_factor_2 {
+  margin: 10px 15%;
+}
+img.scale_factor_3 {
+  margin: 10px 20%;
+}
+img.scale_factor_4 {
+  margin: 10px 25%;
+}
+img.scale_factor_5 {
+  margin: 10px 30%;
+}
+
 reference {
   display: list-item;
 }
@@ -625,10 +645,10 @@ a.gray {
   color: #eee;
 }
 
-
 a.gray:visited {
   color: #eee;
 }
+
 pre.prettyprint{display:block;background-color:#333; cursor: pointer;}pre .nocode{background-color:none;color:#000}pre .str{color:#ffa0a0}pre .kwd{color:#f0e68c;font-weight:bold}pre .com{color:#87ceeb}pre .typ{color:#98fb98}pre .lit{color:#cd5c5c}pre .pun{color:#fff}pre .pln{color:#fff}pre .tag{color:#f0e68c;font-weight:bold}pre .atn{color:#bdb76b;font-weight:bold}pre .atv{color:#ffa0a0}pre .dec{color:#98fb98}ol.linenums{margin-top:0;margin-bottom:0;color:#aeaeae}li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8{list-style-type:none}@media print{pre.prettyprint{background-color:none}pre .str,code .str{color:#060}pre .kwd,code .kwd{color:#006;font-weight:bold}pre .com,code .com{color:#600;font-style:italic}pre .typ,code .typ{color:#404;font-weight:bold}pre .lit,code .lit{color:#044}pre .pun,code .pun{color:#440}pre .pln,code .pln{color:#000}pre .tag,code .tag{color:#006;font-weight:bold}pre .atn,code .atn{color:#404}pre .atv,code .atv{color:#060}}
 pre .str,code .str{color:#fec243}pre .kwd,code .kwd{color:#8470ff}pre .com,code .com{color:#32cd32;font-style:italic}pre .typ,code .typ{color:#6ecbcc}pre .lit,code .lit{color:#d06}pre .pun,code .pun{color:#8b8970}pre .pln,code .pln{color:#0f0f0f}pre .tag,code .tag{color:#9c9cff}pre .htm,code .htm{color:#dda0dd}pre .xsl,code .xsl{color:#d0a0d0}pre .atn,code .atn{color:#46eeee;font-weight:normal}pre .atv,code .atv{color:#eeb4b4}pre .dec,code .dec{color:#3387cc}a{text-decoration:none}pre.prettyprint,code.prettyprint{font-family:'Inconsolata', 'Droid Sans Mono','CPMono_v07 Bold','Droid Sans';font-weight:medium;font-size:9pt;background-color:#0f0f0f;}pre.prettyprint{width:95%;white-space:pre-wrap}pre.prettyprint a,code.prettyprint a{text-decoration:none}ol.linenums{margin-top:0;margin-bottom:0;color:#8b8970}li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8{list-style-type:none}@media print{pre.prettyprint,code.prettyprint{background-color:#fff}pre .str,code .str{color:#088}pre .kwd,code .kwd{color:#006;font-weight:bold}pre .com,code .com{color:#oc3;font-style:italic}pre .typ,code .typ{color:#404;font-weight:bold}pre .lit,code .lit{color:#044}pre .pun,code .pun{color:#440}pre .pln,code .pln{color:#000}pre .tag,code .tag{color:#b66ff7;font-weight:bold}pre .htm,code .htm{color:#606;font-weight:bold}pre .xsl,code .xsl{color:#606;font-weight:bold}pre .atn,code .atn{color:#c71585;font-weight:normal}pre .atv,code .atv{color:#088;font-weight:normal}}
 pre.prettyprint.no-eval {background-color: #fff; cursor: default;} .prettyprint.no-eval span.kwd{color: #f16e6e;}.prettyprint.no-eval span.lit{color: #56bfa2;}
@@ -661,6 +681,7 @@ pre.prettyprint{
     border: none;
 }
 
+
 div.pre-prettyprint > pre.prettyprint.no-eval.prettyprinted {
     border-left: 1ex solid white;
 }
diff --git a/static/img_javascript/Fig5.4c.std.pdf b/static/img_javascript/Fig5.4c.std.pdf
index 9bd723851..3955bf41c 100644
Binary files a/static/img_javascript/Fig5.4c.std.pdf and b/static/img_javascript/Fig5.4c.std.pdf differ
diff --git a/static/img_javascript/Fig5.4c.std.svg b/static/img_javascript/Fig5.4c.std.svg
index f7d7bcc6c..b448450fa 100644
--- a/static/img_javascript/Fig5.4c.std.svg
+++ b/static/img_javascript/Fig5.4c.std.svg
@@ -26,11 +26,11 @@
      guidetolerance="10"
      inkscape:pageopacity="0"
      inkscape:pageshadow="2"
-     inkscape:window-width="640"
-     inkscape:window-height="480"
+     inkscape:window-width="1568"
+     inkscape:window-height="1136"
      id="namedview5781"
      showgrid="false"
-     inkscape:zoom="0.29207921"
+     inkscape:zoom="1.1683168"
      inkscape:cx="215.98286"
      inkscape:cy="136.55563"
      inkscape:window-x="0"
@@ -269,7 +269,7 @@
         <dc:format>image/svg+xml</dc:format>
         <dc:type
            rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
-        <dc:title></dc:title>
+        <dc:title />
       </cc:Work>
     </rdf:RDF>
   </metadata>
@@ -537,7 +537,7 @@
        style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:20px;line-height:125%;font-family:Inconsolata;-inkscape-font-specification:Sans;text-align:center;letter-spacing:0px;word-spacing:0px;text-anchor:middle;display:inline;fill:#383838;fill-opacity:1;stroke:none"><tspan
          x="362.41107"
          y="89.981079"
-         id="tspan6691-7-5-6-0">read</tspan></text>
+         id="tspan6691-7-5-6-0">prompt</tspan></text>
     <text
        x="271.9093"
        y="262.48129"
@@ -630,7 +630,7 @@
        style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:20px;line-height:125%;font-family:Inconsolata;-inkscape-font-specification:Sans;text-align:center;letter-spacing:0px;word-spacing:0px;text-anchor:middle;display:inline;fill:#383838;fill-opacity:1;stroke:none"><tspan
          x="214.63654"
          y="414.52686"
-         id="tspan6691-7-5-6-0-0">print</tspan></text>
+         id="tspan6691-7-5-6-0-0">display</tspan></text>
     <text
        x="250.9093"
        y="194.61612"
diff --git a/static/img_javascript/Fig5.4c.std.svg.pdf b/static/img_javascript/Fig5.4c.std.svg.pdf
index 9b5b89aa3..3955bf41c 100644
Binary files a/static/img_javascript/Fig5.4c.std.svg.pdf and b/static/img_javascript/Fig5.4c.std.svg.pdf differ
diff --git a/xml/chapter1/section2/subsection1.xml b/xml/chapter1/section2/subsection1.xml
index a48335d97..3b0c60503 100644
--- a/xml/chapter1/section2/subsection1.xml
+++ b/xml/chapter1/section2/subsection1.xml
@@ -165,7 +165,6 @@ function factorial(n) {
     We avoided doing this here so as to minimize the number of things to
     think about at
     once.<LABEL NAME="foot:block-structured-factorial"/></FOOTNOTE>
-
     <SNIPPET PAGE="34">
       <NAME>factorial_iterative_definition</NAME>
       <EXAMPLE>factorial_example</EXAMPLE>
diff --git a/xml/chapter1/section3/subsection2.xml b/xml/chapter1/section3/subsection2.xml
index 38126e809..a4e3e15c8 100644
--- a/xml/chapter1/section3/subsection2.xml
+++ b/xml/chapter1/section3/subsection2.xml
@@ -749,10 +749,10 @@ function f(x, y) {
     </SCHEME>
     <JAVASCRIPT>
       Names that are declared with <JAVASCRIPTINLINE>const</JAVASCRIPTINLINE>
-      directly inside of function declarations have the surrounding function as
+      inside of a block have the body of the immediately surrounding block as
       their scope.<FOOTNOTE>
       <LABEL NAME="foot:tdz"/>
-      Note that a name declared in a function using
+      Note that a name declared in a block using
       <JAVASCRIPTINLINE>const</JAVASCRIPTINLINE> cannot be used before the
       declaration fully is evaluated, not even in the right-hand expression
       of the declaration itself, and regardless whether the same name is
diff --git a/xml/chapter1/section3/subsection3.xml b/xml/chapter1/section3/subsection3.xml
index f9a9e567c..15b301ebe 100644
--- a/xml/chapter1/section3/subsection3.xml
+++ b/xml/chapter1/section3/subsection3.xml
@@ -85,7 +85,7 @@
       <SCHEME>procedure that implements this strategy:</SCHEME>
       <JAVASCRIPT>function that implements this strategy:<FOOTNOTE>Note that we
       slightly extend the syntax of conditional statements described in
-      section<SPACE/><REF NAME="sec:lambda"/> by allowing another conditional
+      section<SPACE/><REF NAME="sec:lambda"/> by admitting another conditional
       statement in place of the block following
       <JAVASCRIPTINLINE>else</JAVASCRIPTINLINE>.</FOOTNOTE>
       </JAVASCRIPT>
diff --git a/xml/chapter3/section2/subsection1.xml b/xml/chapter3/section2/subsection1.xml
index ff2cdfc24..b79180de4 100644
--- a/xml/chapter3/section2/subsection1.xml
+++ b/xml/chapter3/section2/subsection1.xml
@@ -213,8 +213,8 @@ const square = x =&gt; x * x;
 	<JAVASCRIPTINLINE>function</JAVASCRIPTINLINE> and
 	<JAVASCRIPTINLINE>let</JAVASCRIPTINLINE>
 	create declarations by	adding bindings to frames.
-	For declarations at the toplevel of the program, outside of any block
-	or function body, we introduce a <EM>program environment</EM>,
+	For declarations at the toplevel of the program, outside of any block,
+	we introduce a <EM>program environment</EM>,
 	consisting of a single frame<EMDASH/>the <EM>program
 	frame</EM><EMDASH/>directly inside the global environment. To reduce
 	clutter, after this figure, we will not	display	the global environment
@@ -479,10 +479,7 @@ const square = x =&gt; x * x;
       <JAVASCRIPT>simple function</JAVASCRIPT>
     </SPLITINLINE>
     application can be summarized by two
-    rules:<SPLITINLINE><JAVASCRIPT><FOOTNOTE>
-    In section<SPACE/><REF NAME="sec:env-internal-def"/>, we shall generalize
-    the first rule to be able to handle functions whose bodies declare local
-    names.</FOOTNOTE></JAVASCRIPT></SPLITINLINE>
+    rules:
     <UL>
       <LI>
 	A
diff --git a/xml/chapter3/section2/subsection4.xml b/xml/chapter3/section2/subsection4.xml
index 2da44bdfc..d9fc50372 100644
--- a/xml/chapter3/section2/subsection4.xml
+++ b/xml/chapter3/section2/subsection4.xml
@@ -21,9 +21,9 @@
     <JAVASCRIPT>
       <TEXT>
 	Section<SPACE/><REF NAME="sec:env-apply-proc"/> describes the application
-	of simple functions according to the substitution model, but fails to
-	handle the case where the body of the function being applied contains
-	constant, function or variable declarations, as in the functions
+	of simple functions according to the environment model, but fails to
+	handle proper blocks that contain contains constant, function or
+	variable declarations, as the bodies of the functions
 	<JAVASCRIPTINLINE>new_withdraw</JAVASCRIPTINLINE> and 
 	<JAVASCRIPTINLINE>make_account</JAVASCRIPTINLINE>
 	of section<SPACE/><REF NAME="sec:local-state-variables"/>,
@@ -31,16 +31,16 @@
 	of section<SPACE/><REF NAME="sec:benefits-of-assignment"/>
 	and in both versions of the factorial function 
 	of section<SPACE/><REF NAME="sec:costs-of-assignment"/>.
-	Our treatment of the declaration of local names within function bodies
+	Our treatment of the declaration of local names within blocks
 	is similar to the treatment of declarations of global names, as for
 	example the name <JAVASCRIPTINLINE>square</JAVASCRIPTINLINE> in
 	section<SPACE/><REF NAME="sec:env-model-rules"/>. We explained
 	that the names declared in the program are added to the program
 	frame. More precisely, before the program gets evaluated, we identify
-	the names that are declared in the program at toplevel. These names
-	are all added to the program frame, and then the program gets evaluated
-	with respect to the program environment. Initially, before the program
-	runs, these names refer to a special value
+	the names that are declared in the program at toplevel (outside of any
+	block). These names are all added to the program frame, and then the
+	program gets evaluated with respect to the program environment.
+	Initially, before the program runs, these names refer to a special value
 	<LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>, and any attempt to
 	access the value of a name that refers to
 	<LATEXINLINE>$\textit{unassigned}$</LATEXINLINE> leads to an error.
@@ -48,50 +48,16 @@
 	in section<SPACE/><REF NAME="sec:env-local-state"/>.
       </TEXT>
       <TEXT>
-	Similar to names that are declared at toplevel, we simply add the
-	names declared locally in a function body to the relevant
-	environment frame
-	before we evaluate the body. The relevant environment frame
-	here is of course the new frame that binds the function's parameters
-	to the values of the arguments. This leads to the final, definitive
-	version of the first of the two rules in
-	section<SPACE/><REF NAME="sec:env-model-rules"/> that summarize
-	the environment model of function application. The second rule
-	is copied here for completeness; it hasn<APOS/>t changed.
-	<UL>
-	  <LI>
-	    A function object is applied to a set of arguments by constructing a
-	    frame, in which we create variable bindings for the parameters of the
-	    function to the arguments of the call, <EM>and constant/variable
-	    bindings for the local constants/variable declarations in the body
-	    of the function,</EM> and then evaluating the body in the context of
-	    the new environment constructed. The new frame has as its enclosing
-	    environment the environment part of the function object being
-	    applied. <EM>The local constant/variable names intially refer to
-	    the value <LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>, before
-	    the body is evaluated.</EM>
-	    <INDEX>function
-	    <SUBINDEX>creating with lambda</SUBINDEX></INDEX>
-	    <!--\indcodeplus{lambda}{expression}[value of]-->
-	  </LI>
-	  <LI>
-	    A function is created by evaluating a 
-	    lambda expression relative to a given environment.  The resulting
-	    function object is a pair consisting of the text of the lambda
-	    expression and a pointer to the environment in which the function
-	    was created.
-	  </LI>
-	</UL>
-	We apply the same idea to names that are declared within blocks, such
-	as the consequent or alternative block of conditional statements, which
-	we introduced in section<SPACE/><REF NAME="sec:lambda"/>: A block
-	is evaluated by extending the current environment with a new frame.
-	The constant/variable names declared within the block intially refer
-	to the value <LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>, before
-	the body of the block is evaluated.<FOOTNOTE>Equipped with a deeper
-	understanding of the scope of names, we can now explain why the program
-	in footnote<SPACE/><REF NAME="foot:tdz"/> of chapter 1 goes
-	wrong.</FOOTNOTE>
+	In order to evaluate a block in a given environment, we extend the
+	environment by a new frame that contains all names declared locally
+	(outside of nested blocks) in the block body. These names intially refer
+	to the value <LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>, when the
+	evaluation of the body commences. The evaluation of local constant
+	and variable declarations then re-assign the names to the left of the
+	equal sign, as if the declaration was an assignment.<FOOTNOTE>Equipped
+	with a deeper understanding of the scope of names, we can now explain
+	why the program in footnote<SPACE/><REF NAME="foot:tdz"/> of chapter 1
+	goes wrong.</FOOTNOTE>
       </TEXT>
     </JAVASCRIPT>
   </SPLIT>
@@ -225,21 +191,21 @@ function sqrt(x) {
       <JAVASCRIPT>program</JAVASCRIPT>
     </SPLITINLINE>
     environment, in which the parameter <SCHEMEINLINE>x</SCHEMEINLINE> is bound
-    <SPLITINLINE>
+    to 2.
+    <SPLIT>
       <SCHEME>
-	to 2.
+	The body of sqrt was then evaluated in E1. Since the first expression
+	in the body of <SCHEMEINLINE>sqrt</SCHEMEINLINE> is
       </SCHEME>
       <JAVASCRIPT>
-	to 2, and in which the locally declared names
-	<JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>,
-	<JAVASCRIPTINLINE>improve</JAVASCRIPTINLINE> and
-	<JAVASCRIPTINLINE>sqrt_iter</JAVASCRIPTINLINE> are bound to
-	the value <LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>.
+	The body of <SCHEMEINLINE>sqrt</SCHEMEINLINE> was then evaluated in
+	E1. That body in this case is a block with local
+	function declarations and therefore we extended E1 with a new frame for
+	those declarations, resulting in the new environment E2. The body
+	of the block was then evaluated in E2. Since the first statement
+	in the body is
       </JAVASCRIPT>
-    </SPLITINLINE>
-    The body of <SCHEMEINLINE>sqrt</SCHEMEINLINE> was then evaluated in
-    E1.  Since the first expression in the body of
-    <SCHEMEINLINE>sqrt</SCHEMEINLINE> is
+    </SPLIT>
     <SNIPPET EVAL="no">
       <REQUIRES>abs_definition</REQUIRES>
       <REQUIRES>square_definition</REQUIRES>
@@ -253,38 +219,31 @@ function good_enough(guess) {
 }
       </JAVASCRIPT>
     </SNIPPET>
-    evaluating this expression defined the
-    <SPLITINLINE>
-      <SCHEME>procedure</SCHEME>
-      <JAVASCRIPT>function</JAVASCRIPT>
-    </SPLITINLINE>
-    <SPLITINLINE>
-      <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME>
-      <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE></JAVASCRIPT>
-    </SPLITINLINE>
-    in the environment<SPACE/>E1.
     <SPLIT>
       <SCHEME>
-	To<SPACE/>be more precise, the
-	symbol 
-	<SPLITINLINE>
-	  <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME>
-	  <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>
-	  </JAVASCRIPT>
-	</SPLITINLINE>
-	was added to the first frame of E1, bound to a
-	<SPLITINLINE>
-	  <SCHEME>procedure</SCHEME>
-	  <JAVASCRIPT>function</JAVASCRIPT>
-	</SPLITINLINE>
+	evaluating this expression defined the procedure
+	<SCHEMEINLINE>good-enough?</SCHEMEINLINE>
+	in the environment<SPACE/>E1.
+      </SCHEME>
+      <JAVASCRIPT>
+	evaluating this declaration created the function
+	<JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>
+	in the environment<SPACE/>E2.
+      </JAVASCRIPT>
+    </SPLIT>
+    <SPLIT>
+      <SCHEME>
+	To<SPACE/>be more precise, the symbol 
+	<SCHEMEINLINE>good-enough?</SCHEMEINLINE> was added to the first frame
+	of E1, bound to a procedure
 	object whose associated environment is E1.
       </SCHEME>
       <JAVASCRIPT>
 	To<SPACE/>be more precise, the value
 	<LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>
 	for the symbol <JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>
-	in the first frame of E1 is bound to a function
-	object whose associated environment is E1.
+	in the first frame of E2 was replaced by a function
+	object whose associated environment is E2.
       </JAVASCRIPT>
     </SPLIT>
     Similarly,
@@ -295,10 +254,10 @@ function good_enough(guess) {
     </SPLITINLINE>
     were defined as
     <SPLITINLINE>
-      <SCHEME>procedures</SCHEME>
-      <JAVASCRIPT>functions</JAVASCRIPT>
+      <SCHEME>procedures in E1.</SCHEME>
+      <JAVASCRIPT>functions in E2.</JAVASCRIPT>
     </SPLITINLINE>
-    in E1.  For conciseness,
+    For conciseness,
     <SPLITINLINE>
       <SCHEME>
 	figure<SPACE/><REF NAME="fig:sqrt-internal_scheme"/>
@@ -331,18 +290,28 @@ function good_enough(guess) {
       <JAVASCRIPT><JAVASCRIPTINLINE>sqrt_iter(1.0)</JAVASCRIPTINLINE>
       </JAVASCRIPT>
     </SPLITINLINE>
-    was evaluated, still in environment E1.  So the
+    was evaluated, still in environment
+    <SPLITINLINE>
+      <SCHEME>E1.</SCHEME>
+      <JAVASCRIPT>E2.</JAVASCRIPT>
+    </SPLITINLINE>
+    So the
     <SPLITINLINE>
       <SCHEME>procedure</SCHEME>
       <JAVASCRIPT>function</JAVASCRIPT>
     </SPLITINLINE>
     object bound to 
     <SPLITINLINE>
-      <SCHEME><SCHEMEINLINE>sqrt-iter</SCHEMEINLINE></SCHEME>
-      <JAVASCRIPT><JAVASCRIPTINLINE>sqrt_iter</JAVASCRIPTINLINE></JAVASCRIPT>
+      <SCHEME><SCHEMEINLINE>sqrt-iter</SCHEMEINLINE>
+      in E1 was called with 1 as an argument.  This created an environment E2
+      in which
+      </SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>sqrt_iter</JAVASCRIPTINLINE>
+      in E2 was called with 1 as an argument.  This created an environment E3
+      in which
+      </JAVASCRIPT>
     </SPLITINLINE>
-    in E1 was called with 1 as an argument.  This created an environment E2 in
-    which <SCHEMEINLINE>guess</SCHEMEINLINE>, the parameter of 
+    <SCHEMEINLINE>guess</SCHEMEINLINE>, the parameter of 
     <SPLITINLINE>
       <SCHEME><SCHEMEINLINE>sqrt-iter</SCHEMEINLINE>,</SCHEME>
       <JAVASCRIPT><JAVASCRIPTINLINE>sqrt_iter</JAVASCRIPTINLINE>,</JAVASCRIPT>
@@ -358,17 +327,29 @@ function good_enough(guess) {
       <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME>
       <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE></JAVASCRIPT>
     </SPLITINLINE>
-    with the value of <SCHEMEINLINE>guess</SCHEMEINLINE> (from E2) as the
-    argument for 
+    with the value of <SCHEMEINLINE>guess</SCHEMEINLINE>
     <SPLITINLINE>
-      <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE>.</SCHEME>
-      <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>.</JAVASCRIPT>
+      <SCHEME>
+	(from E2) as the argument for 
+	<SCHEMEINLINE>good-enough?</SCHEMEINLINE>.
+      </SCHEME>
+      <JAVASCRIPT>
+	(from E3) as the argument for 
+	<JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>.
+      </JAVASCRIPT>
     </SPLITINLINE>
-    This set up another environment, E3, in which
-    <SCHEMEINLINE>guess</SCHEMEINLINE> (the parameter of 
+    This set up another environment,
     <SPLITINLINE>
-      <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE>)</SCHEME>
-      <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>)</JAVASCRIPT>
+      <SCHEME>
+	E3, in which
+	<SCHEMEINLINE>guess</SCHEMEINLINE> (the parameter of 
+	<SCHEMEINLINE>good-enough?</SCHEMEINLINE>)
+      </SCHEME>
+      <JAVASCRIPT>
+	E4, in which
+	<SCHEMEINLINE>guess</SCHEMEINLINE> (the parameter of 
+	<JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>)
+      </JAVASCRIPT>
     </SPLITINLINE>
     is bound to 1. Although 
     <SPLITINLINE>
@@ -381,22 +362,23 @@ function good_enough(guess) {
       <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE></JAVASCRIPT>
     </SPLITINLINE>
     both have a parameter named <SCHEMEINLINE>guess</SCHEMEINLINE>, these are two
-    distinct local variables located in different frames.  Also, E2 and E3 both
-    have E1 as their enclosing environment, because the 
-    <SPLITINLINE>
-      <SCHEME><SCHEMEINLINE>sqrt-iter</SCHEMEINLINE></SCHEME>
-      <JAVASCRIPT><JAVASCRIPTINLINE>sqrt_iter</JAVASCRIPTINLINE></JAVASCRIPT>
-    </SPLITINLINE>
-    and 
-    <SPLITINLINE>
-      <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME>
-      <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE></JAVASCRIPT>
-    </SPLITINLINE>
-    <SPLITINLINE>
-      <SCHEME>procedures</SCHEME>
-      <JAVASCRIPT>functions</JAVASCRIPT>
-    </SPLITINLINE>
-    both have E1 as their environment part.  One consequence of this is that the
+    distinct local variables located in different frames.
+    <SPLIT>
+      <SCHEME>
+	Also, E2 and E3 both have E1 as their enclosing environment, because the 
+	<SCHEMEINLINE>sqrt-iter</SCHEMEINLINE> and 
+	<SCHEMEINLINE>good-enough?</SCHEMEINLINE> procedures
+	both have E1 as their environment part.
+      </SCHEME>
+      <JAVASCRIPT>
+	Also, E3 and E4 both have E2 as their enclosing environment, because the 
+	<JAVASCRIPT><JAVASCRIPTINLINE>sqrt_iter</JAVASCRIPTINLINE></JAVASCRIPT>
+	and 
+	<JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE>
+	both have E2 as their environment part.
+      </JAVASCRIPT>
+    </SPLIT>
+    One consequence of this is that the
     symbol <SCHEMEINLINE>x</SCHEMEINLINE> that appears in the body of 
     <SPLITINLINE>
       <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME>
@@ -440,10 +422,10 @@ function good_enough(guess) {
 	</SPLITINLINE>
 	names will be bound in the frame that the
 	<SPLITINLINE>
-	  <SCHEME>procedure</SCHEME>
-	  <JAVASCRIPT>function</JAVASCRIPT>
+	  <SCHEME>procedure creates when it is run,</SCHEME>
+	  <JAVASCRIPT>block creates when it is evaluated,</JAVASCRIPT>
 	</SPLITINLINE>
-	creates when it is run, rather than being bound in the
+	rather than being bound in the
 	<SPLITINLINE>
 	  <SCHEME>global</SCHEME>
 	  <JAVASCRIPT>program</JAVASCRIPT>
@@ -461,14 +443,14 @@ function good_enough(guess) {
 	  <SCHEME>procedure,</SCHEME>
 	  <JAVASCRIPT>function,</JAVASCRIPT>
 	</SPLITINLINE>
-	simply by using parameter names as free variables. This is because the
-	body of the local
+	simply by using parameter names as free variables. This is
+	because the body of the local
 	<SPLITINLINE>
 	  <SCHEME>procedure</SCHEME>
 	  <JAVASCRIPT>function</JAVASCRIPT>
 	</SPLITINLINE>
-	is evaluated in an environment that is subordinate to the evaluation
-	environment for the enclosing
+	is evaluated in an environment that is subordinate to the
+	evaluation environment for the enclosing
 	<SPLITINLINE>
 	  <SCHEME>procedure.</SCHEME>
 	  <JAVASCRIPT>function.</JAVASCRIPT>
diff --git a/xml/chapter4/section1/section1.xml b/xml/chapter4/section1/section1.xml
index 76182054d..eba2091ec 100644
--- a/xml/chapter4/section1/section1.xml
+++ b/xml/chapter4/section1/section1.xml
@@ -71,55 +71,68 @@
     <SPLITINLINE>
       <SCHEME>Recall that the model has two basic parts:</SCHEME>
       <JAVASCRIPT>
-	The ultimate refinement of the model in
-	section<SPACE/><REF NAME="sec:env-internal-def"/> specifies the
+	Recall that the model specifies the
 	evaluation of function application in two basic steps:
       </JAVASCRIPT>
     </SPLITINLINE>
   </TEXT>
 
-  <SPLIT>
-    <SCHEME>
-      <TEXT>
-	<OL>
-	  <LI> 
+  <TEXT>
+    <OL>
+      <LI> 
+	<SPLIT>
+	  <SCHEME>
             To evaluate a combination (a compound expression other than a 
             special form), evaluate the subexpressions and then apply the value
 	    of the operator subexpression to the values of the operand
             subexpressions.
-	  </LI>
-	  <LI>
-            To apply a compound procedure to a set of arguments, evaluate the
-            body of the procedure in a new environment.  To construct this
-            environment, extend the environment part of the procedure object by a
-            frame in which the formal parameters of the procedure are bound to
-	    the arguments to which the procedure is applied.
-	  </LI>
-	</OL>
-      </TEXT>
-    </SCHEME>
-    <JAVASCRIPT>
-      <TEXT>
-	<OL>
-	  <LI>
+	  </SCHEME>
+	  <JAVASCRIPT>
 	    To evaluate a function application, evaluate the function
 	    subexpression and the argument subexpressions, and then apply the
 	    value of the function subexpression to the values of the argument
             subexpressions.
-	  </LI>
-	  <LI>
-	    To apply a function to a set of arguments, evaluate the body of the
-	    function in a new environment.  To construct this environment,
-	    extend the environment part of the function object by a frame in
-	    which the formal parameters of the function are bound to the
-	    arguments to which the function is applied, and in which the names
-	    of constants and variables declared in the body of the function are
-	    bound to the value <LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>.
-	  </LI>
-	</OL>
-      </TEXT>
-    </JAVASCRIPT>
-  </SPLIT>
+	  </JAVASCRIPT>
+	</SPLIT>
+      </LI>
+      <LI>
+        To apply a compound
+	<SPLITINLINE>
+	  <SCHEME>procedure</SCHEME>
+	  <JAVASCRIPT>function</JAVASCRIPT>
+	</SPLITINLINE>
+	to a set of arguments, evaluate the
+        body of the
+	<SPLITINLINE>
+	  <SCHEME>procedure</SCHEME>
+	  <JAVASCRIPT>function</JAVASCRIPT>
+	</SPLITINLINE>
+	in a new environment.  To construct this
+        environment, extend the environment part of the
+	<SPLITINLINE>
+	  <SCHEME>procedure</SCHEME>
+	  <JAVASCRIPT>function</JAVASCRIPT>
+	</SPLITINLINE>
+	object by a
+        frame in which the
+	<SPLITINLINE>
+	  <SCHEME>formal</SCHEME>
+	</SPLITINLINE>
+	parameters of the
+	<SPLITINLINE>
+	  <SCHEME>procedure</SCHEME>
+	  <JAVASCRIPT>function</JAVASCRIPT>
+	</SPLITINLINE>
+	are bound to
+	the arguments to which the
+	<SPLITINLINE>
+	  <SCHEME>procedure</SCHEME>
+	  <JAVASCRIPT>function</JAVASCRIPT>
+	</SPLITINLINE>
+	is applied.
+      </LI>
+    </OL>
+  </TEXT>
 
   <TEXT>
     <SPLITINLINE>
diff --git a/xml/chapter4/section1/subsection1.xml b/xml/chapter4/section1/subsection1.xml
index 1a08c20ab..d2da38769 100644
--- a/xml/chapter4/section1/subsection1.xml
+++ b/xml/chapter4/section1/subsection1.xml
@@ -278,7 +278,7 @@
 	      The operator symbol is the name of the function being applied, and
 	      the operands are the arguments. Thus 
 	      <JAVASCRIPTINLINE>evaluate</JAVASCRIPTINLINE> does not need any
-	      rules for operators.
+	      rules for operators combinations.
 	    </LI>
 	    <LI>
 	      For a function application,
@@ -357,7 +357,7 @@ function evaluate(stmt, env) {
           ? eval_return(stmt, env)
           : is_application(stmt)
           ? apply(evaluate(function_expression(stmt), env),
-                  map(arg => evaluate(arg, env), args(stmt)))
+                  list_of_values(args(stmt), env))
           : error(stmt, "Unknown syntax in evaluate:");
 }
       </JAVASCRIPT>
@@ -483,35 +483,27 @@ evaluate(my_program, the_empty_environment);
       <SCHEME>expressions that make up the body of the procedure.</SCHEME>
       <JAVASCRIPT>statements that make up the body of the function.</JAVASCRIPT>
     </SPLITINLINE>
-    <SPLIT>
-      <SCHEME>
-	The environment for the evaluation of the body of a compound procedure
-	is constructed by extending the base environment carried by the
-	procedure to include a frame that binds the parameters of the procedure
-	to the arguments to which the procedure is to be applied. 
-      </SCHEME>
-      <JAVASCRIPT>
-	The environment for the evaluation of the body of a compound function
-	is constructed by extending the base environment carried by the function
-        to include a frame that binds the parameters of the function to the
-	arguments to which the function is to be applied, and the body's local
-	names to a special value <JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE>.
-	Any name declared with <JAVASCRIPTINLINE>const</JAVASCRIPTINLINE>
-	or <JAVASCRIPTINLINE>let</JAVASCRIPTINLINE> will refer to this value
-	until its declaration gets evaluated. To make sure that the value of
-	<JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE> is different from any
-	other value in the interpreter, we declare it as follows:
-	<SNIPPET PAGE="379">
-	  <NAME>unassigned</NAME>
-	  <JAVASCRIPT>
-const unassigned = () => null;
-	  </JAVASCRIPT>
-	</SNIPPET>
-	The purpose of the lambda expression is purely to create a unique
-	identity; the function will never be applied and its return value
-	(here <JAVASCRIPTINLINE>null</JAVASCRIPTINLINE>) is irrelevant.
-      </JAVASCRIPT>
-    </SPLIT>
+    The environment for the evaluation of the body of a compound
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is constructed by extending the base environment carried by the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    to include a frame that binds the parameters of the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    to the arguments to which the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is to be applied. 
     Here is the definition of <SCHEMEINLINE>apply</SCHEMEINLINE>:
     <SNIPPET PAGE="366">
       <NAME>apply</NAME>
@@ -537,14 +529,11 @@ function apply(fun, args) {
    if (is_primitive_function(fun)) {
       return apply_primitive_function(fun, args);
    } else if (is_compound_function(fun)) {
-      const body = function_body(fun);
-      const locals = scan_out_declarations(body);
-      const symbols = append(function_parameters(fun), locals);
-      const unassigneds = map(_ => unassigned, locals);
-      const values = append(args, unassigneds);
-      const result = evaluate(body,
-                       extend_environment(symbols, values,
-                         function_environment(fun)));
+      const result = evaluate(function_body(fun),
+                         extend_environment(
+                             function_parameters(fun),
+                             args,
+                             function_environment(fun)));
       return is_return_value(result)
              ? return_value_content(result)
              : undefined;
@@ -554,6 +543,11 @@ function apply(fun, args) {
 }
       </JAVASCRIPT>
     </SNIPPET>
+    <COMMENT>
+      The name <JAVASCRIPTINLINE>arguments</JAVASCRIPTINLINE>
+      is reserved in JavaScript's strict mode. We chose
+      <JAVASCRIPTINLINE>args</JAVASCRIPTINLINE> instead.
+    </COMMENT>
     <SNIPPET PAGE="366" HIDE="yes">
       <NAME>apply_example</NAME>
       <REQUIRES>functions_4_1_1</REQUIRES>
@@ -567,46 +561,7 @@ apply(plus, list(1, 2));
     </SNIPPET>
     
     <SPLIT>
-      <SCHEME></SCHEME>
       <JAVASCRIPT>
-	The function <JAVASCRIPTINLINE>scan_out_declarations</JAVASCRIPTINLINE>
-	collects the list of all names declared in the body statements. For a
-	name to be included in the list, it needs to be declared outside of any
-	other block or function.
-	<SNIPPET>
-          <NAME>scan_out_declarations</NAME>
-	  <EXAMPLE>scan_out_declarations_example</EXAMPLE>
-	  <EXPECTED>[ 'x', [ 'y', null ] ]</EXPECTED>
-          <JAVASCRIPT>
-function scan_out_declarations(stmt) {
-    if (is_sequence(stmt)) {
-        const stmts = sequence_statements(stmt);
-        return is_empty_sequence(stmts)
-            ? null
-            : append(scan_out_declarations(first_statement(stmts)),
-                     scan_out_declarations(make_sequence(
-                                   rest_statements(stmts))));
-    } else {
-       return is_constant_declaration(stmt)
-              ? list(constant_declaration_symbol(stmt))
-              : is_variable_declaration(stmt)
-                ? list(variable_declaration_symbol(stmt))
-                : null;
-    }
-}
-          </JAVASCRIPT>
-	</SNIPPET>
-
-	<SNIPPET HIDE="yes">
-          <NAME>scan_out_declarations_example</NAME>
-	  <REQUIRES>functions_4_1_1</REQUIRES>
-	  <REQUIRES>functions_4_1_2</REQUIRES>
-	  <REQUIRES>functions_4_1_3</REQUIRES>
-	  <REQUIRES>functions_4_1_4</REQUIRES>
-          <JAVASCRIPT>
-scan_out_declarations(parse("const x = 1; let y = 2;"));
-	  </JAVASCRIPT>
-	</SNIPPET>
 	In order to return a value, JavaScript functions need to evaluate a
 	return statement. If a function terminates without return, the value 
 	<JAVASCRIPTINLINE>undefined</JAVASCRIPTINLINE> is returned. Thus, if
@@ -617,75 +572,145 @@ scan_out_declarations(parse("const x = 1; let y = 2;"));
     </SPLIT>
   </TEXT>
 
-  <SPLIT>
-    <SCHEME>
-
-      <SUBHEADING>
-	<NAME>Procedure	arguments</NAME>
-      </SUBHEADING>
+  <SUBHEADING>
+    <NAME>
+    <SPLITINLINE>
+      <SCHEME>Procedure</SCHEME>
+      <JAVASCRIPT>Function</JAVASCRIPT>
+    </SPLITINLINE>
+      arguments
+    </NAME>
+  </SUBHEADING>
 
-      <TEXT>
-	When <SCHEMEINLINE>eval</SCHEMEINLINE> processes a procedure
-	application, it uses <SCHEMEINLINE>list-of-values</SCHEMEINLINE>
-	to produce the list of arguments to which the procedure is to be applied.
-	<SCHEMEINLINE>List-of-values</SCHEMEINLINE> takes as an argument the
-	operands of the combination. It evaluates each operand and returns a
-	list of the corresponding values:<FOOTNOTE>We could have simplified the 
-	<SCHEMEINLINE>application?</SCHEMEINLINE> clause in
-	<SCHEMEINLINE>eval</SCHEMEINLINE> by using
-	<SCHEMEINLINE>map</SCHEMEINLINE> (and stipulating that
-	<SCHEMEINLINE>operands</SCHEMEINLINE> returns a list) rather than writing
-	an explicit <SCHEMEINLINE>list-of-values</SCHEMEINLINE> procedure. We
-	chose not to use <SCHEMEINLINE>map</SCHEMEINLINE> here to emphasize the
-	fact that the
-	<INDEX>metacircular evaluator for Scheme<SUBINDEX>higher-order
-	<SPLITINLINE><SCHEME>procedures</SCHEME>
-	<JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE> in </SUBINDEX></INDEX>
-	<INDEX>higher-order <SPLITINLINE><SCHEME>procedures</SCHEME>
-	<JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-	<SUBINDEX>in metacircular evaluator</SUBINDEX></INDEX>
-	evaluator can be implemented without any use of higher-order
-	procedures (and thus could be written in a language that doesn<APOS/>t
-	have higher-order procedures), even though the language that it supports
-	will include higher-order procedures.
-	<LABEL NAME="foot:mceval-higher-order"/></FOOTNOTE>
-	<SNIPPET PAGE="367">
-	  <NAME>list_of_values</NAME>
-	  <EXAMPLE>list_of_values_example</EXAMPLE>
-	  <SCHEME>
+  <TEXT>
+    When
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>eval</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><SCHEMEINLINE>evaluate</SCHEMEINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    processes a
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    application, it uses
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>list-of-values</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>list_of_values</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to produce the list of arguments to which the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is to be applied.
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>List-of-values</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>The function
+      <JAVASCRIPTINLINE>list_of_values</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    takes as an argument the
+    <SPLITINLINE>
+      <SCHEME>operands of the combination.</SCHEME>
+      <JAVASCRIPT>arguments of the application.</JAVASCRIPT>
+    </SPLITINLINE>
+    It evaluates each
+    <SPLITINLINE>
+      <SCHEME>operand</SCHEME>
+      <JAVASCRIPT>argument</JAVASCRIPT>
+    </SPLITINLINE>
+    and returns a
+    list of the corresponding values:<FOOTNOTE>We could have simplified the 
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>application?</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>is_application</SCHEMEINLINE>function
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    clause in
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>eval</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><SCHEMEINLINE>evaluate</SCHEMEINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    by using
+    <SCHEMEINLINE>map</SCHEMEINLINE> (and stipulating that
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>operands</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><SCHEMEINLINE>args</SCHEMEINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    returns a list) rather than writing
+    an explicit
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>list-of-values</SCHEMEINLINE> procedure.</SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>list_of_values</JAVASCRIPTINLINE>
+      function.
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    We chose not to use <SCHEMEINLINE>map</SCHEMEINLINE> here to emphasize the
+    fact that the
+    <INDEX>metacircular evaluator for Scheme<SUBINDEX>higher-order
+    <SPLITINLINE><SCHEME>procedures</SCHEME>
+    <JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE> in </SUBINDEX></INDEX>
+    <INDEX>higher-order <SPLITINLINE><SCHEME>procedures</SCHEME>
+    <JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
+    <SUBINDEX>in metacircular evaluator</SUBINDEX></INDEX>
+    evaluator can be implemented without any use of higher-order
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    (and thus could be written in a language that doesn<APOS/>t
+    have higher-order
+    <SPLITINLINE>
+      <SCHEME>procedures),</SCHEME>
+      <JAVASCRIPT>functions),</JAVASCRIPT>
+    </SPLITINLINE>
+    even though the language that it supports
+    will include higher-order
+    <SPLITINLINE>
+      <SCHEME>procedures.</SCHEME>
+      <JAVASCRIPT>functions.</JAVASCRIPT>
+    </SPLITINLINE>
+    <LABEL NAME="foot:mceval-higher-order"/></FOOTNOTE>
+    <SNIPPET PAGE="367">
+      <NAME>list_of_values</NAME>
+      <EXAMPLE>list_of_values_example</EXAMPLE>
+      <SCHEME>
 (define (list-of-values exps env)
   (if (no-operands? exps)
       \&apos;()
       (cons (eval (first-operand exps) env)
             (list-of-values (rest-operands exps) env))))
-	  </SCHEME>
-	</SNIPPET>
-	<SNIPPET PAGE="365" HIDE="yes">
-	  <NAME>list_of_values_example</NAME>
-	  <REQUIRES>functions_4_1_1</REQUIRES>
-	  <REQUIRES>functions_4_1_2</REQUIRES>
-	  <REQUIRES>functions_4_1_3</REQUIRES>
-	  <REQUIRES>functions_4_1_4</REQUIRES>
-	  <SCHEME>
+      </SCHEME>
+      <JAVASCRIPT>
+function list_of_values(exps, env) {
+     return no_args(exps)
+         ? null
+         : pair(evaluate(first_arg(exps), env),
+                list_of_values(rest_args(exps), env));
+}
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SNIPPET PAGE="365" HIDE="yes">
+      <NAME>list_of_values_example</NAME>
+      <REQUIRES>functions_4_1_1</REQUIRES>
+      <REQUIRES>functions_4_1_2</REQUIRES>
+      <REQUIRES>functions_4_1_3</REQUIRES>
+      <REQUIRES>functions_4_1_4</REQUIRES>
+      <SCHEME>
 (define the-global-environment (setup-environment))
 (eval (read) the-global-environment)
-	  </SCHEME>
-	  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 const my_addition_expression = parse("1 + 2;");
 list_of_values(list(1, my_addition_expression, 7),
                the_global_environment);
-	  </JAVASCRIPT>
-	</SNIPPET>
-      </TEXT>
-    </SCHEME>
-    <JAVASCRIPT>
-	<SNIPPET PAGE="365" HIDE="yes">
-	  <NAME>list_of_values</NAME>
-	  <JAVASCRIPT>
-	  </JAVASCRIPT>
-	</SNIPPET>
-    </JAVASCRIPT>
-  </SPLIT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
   
   <SUBHEADING>
     <NAME>
@@ -820,9 +845,9 @@ eval_conditional_expression(my_cond_expr, the_empty_environment);
     <JAVASCRIPT>
       <TEXT>
 	The function <JAVASCRIPTINLINE>eval_sequence</JAVASCRIPTINLINE>
-	is used by <JAVASCRIPTINLINE>eval</JAVASCRIPTINLINE>
-	to evaluate a sequence of statements at the toplevel, in a function body
-	or in a block. It takes as arguments a sequence of statements and an
+	is used by <JAVASCRIPTINLINE>evaluate</JAVASCRIPTINLINE>
+	to evaluate a sequence of statements at the toplevel, in a block.
+	It takes as arguments a sequence of statements and an
 	environment, and evaluates the statements in the order in which they
 	occur. The value returned is the value of the final statement, except
 	if the result of evaluating any statement in the sequence yields
@@ -881,10 +906,22 @@ eval_sequence(my_sequence, the_empty_environment);
 	The evaluation of block statements evaluates the body of the
 	block with respect to an environment that extends the current
 	environment with a binding of the local names of the block
-	body to <JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE>.
+	body to a special value
+	<JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE>.
 	<SNIPPET PAGE="367">
-          <NAME>eval_block</NAME>
+          <NAME>list_of_unassigned</NAME>
 	  <REQUIRES>unassigned</REQUIRES>
+          <JAVASCRIPT>
+function list_of_unassigned(names) {
+    return is_null(names)
+        ? null
+        : pair(unassigned, list_of_unassigned(tail(names)));	    
+}
+	  </JAVASCRIPT>
+	</SNIPPET>
+	<SNIPPET PAGE="367">
+          <NAME>eval_block</NAME>
+          <REQUIRES>list_of_unassigned</REQUIRES>
           <REQUIRES>scan_out_declarations</REQUIRES>
 	  <EXAMPLE>eval_block_example</EXAMPLE>
 	  <EXPECTED>42</EXPECTED>
@@ -892,13 +929,61 @@ eval_sequence(my_sequence, the_empty_environment);
 function eval_block(stmt, env) {
     const body = block_body(stmt);
     const locals = scan_out_declarations(body);
-    const unassigneds = map(_ => unassigned, locals);
+    const unassigneds = list_of_unassigned(locals);
     return evaluate(body,
                 extend_environment(locals, unassigneds, env));
 }
           </JAVASCRIPT>
 	</SNIPPET>
-
+	The function <JAVASCRIPTINLINE>scan_out_declarations</JAVASCRIPTINLINE>
+	collects the list of all names declared in the body statements. For a
+	name to be included in the list, it needs to be declared outside of any
+	other block.
+	<SNIPPET>
+          <NAME>scan_out_declarations</NAME>
+	  <EXAMPLE>scan_out_declarations_example</EXAMPLE>
+	  <EXPECTED>[ 'x', [ 'y', null ] ]</EXPECTED>
+          <JAVASCRIPT>
+function scan_out_declarations(stmt) {
+    if (is_sequence(stmt)) {
+        const stmts = sequence_statements(stmt);
+        return is_empty_sequence(stmts)
+            ? null
+            : append(scan_out_declarations(first_statement(stmts)),
+                     scan_out_declarations(make_sequence(
+                                   rest_statements(stmts))));
+    } else {
+       return is_constant_declaration(stmt)
+              ? list(constant_declaration_symbol(stmt))
+              : is_variable_declaration(stmt)
+                ? list(variable_declaration_symbol(stmt))
+                : null;
+    }
+}
+          </JAVASCRIPT>
+	</SNIPPET>
+	<SNIPPET HIDE="yes">
+          <NAME>scan_out_declarations_example</NAME>
+	  <REQUIRES>functions_4_1_1</REQUIRES>
+	  <REQUIRES>functions_4_1_2</REQUIRES>
+	  <REQUIRES>functions_4_1_3</REQUIRES>
+	  <REQUIRES>functions_4_1_4</REQUIRES>
+          <JAVASCRIPT>
+scan_out_declarations(parse("const x = 1; let y = 2;"));
+	  </JAVASCRIPT>
+	</SNIPPET>
+	To make sure that the value of
+	<JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE> is different from any
+	other value in the interpreter, we declare it as follows:
+	<SNIPPET PAGE="379">
+	  <NAME>unassigned</NAME>
+	  <JAVASCRIPT>
+const unassigned = () => null;
+	  </JAVASCRIPT>
+	</SNIPPET>
+	The purpose of the lambda expression is purely to create a unique
+	identity; the function will never be applied and its return value
+	(here <JAVASCRIPTINLINE>null</JAVASCRIPTINLINE>) is irrelevant.
 	<SNIPPET PAGE="367" HIDE="yes">
           <NAME>eval_block_example</NAME>
 	  <REQUIRES>functions_4_1_1</REQUIRES>
@@ -1175,7 +1260,7 @@ evaluate(my_program, the_global_environment);
 function parse_and_evaluate(input) {
     const program = parse(input);
     const locals = scan_out_declarations(program);
-    const unassigneds = map(x => unassigned, locals);
+    const unassigneds = list_of_unassigned(locals);
     const program_env = extend_environment(locals, unassigneds,
                                        the_global_environment);
     return evaluate(program, program_env);
diff --git a/xml/chapter4/section1/subsection2.xml b/xml/chapter4/section1/subsection2.xml
index 16dad9ff7..6dc3695fb 100644
--- a/xml/chapter4/section1/subsection2.xml
+++ b/xml/chapter4/section1/subsection2.xml
@@ -517,6 +517,8 @@ display(variable_declaration_value(my_declaration_statement));
 // FIXME: replace "function_definition" with "lambda"
 // after this issue is handled:
 // https://github.com/source-academy/js-slang/issues/634
+// FIXME: remove the block from lambda_body once the
+// parser wraps the body in a block whenever needed.
 function is_lambda(stmt) {
    return is_tagged_list(stmt, "function_definition");
 }
@@ -524,7 +526,7 @@ function lambda_parameters(stmt) {
    return map(symbol_of_name, head(tail(stmt)));
 }
 function lambda_body(stmt) {
-   return head(tail(tail(stmt)));
+   return make_block(head(tail(tail(stmt))));
 }
 	      </JAVASCRIPT>
 	    </SNIPPET>
diff --git a/xml/chapter4/section1/subsection3.xml b/xml/chapter4/section1/subsection3.xml
index 6d1c00820..a5e0f2afa 100644
--- a/xml/chapter4/section1/subsection3.xml
+++ b/xml/chapter4/section1/subsection3.xml
@@ -616,7 +616,6 @@ tail(head(extend_environment(list("x", "y", "z"),
     error.
     <SNIPPET PAGE="379">
       <NAME>lookup_variable_value</NAME>
-      <REQUIRES>unassigned</REQUIRES>
       <EXAMPLE>lookup_variable_value_example</EXAMPLE>
       <EXPECTED>1</EXPECTED>
       <SCHEME>
diff --git a/xml/chapter4/section1/subsection4.xml b/xml/chapter4/section1/subsection4.xml
index b1dc0fe4f..8bfcc790b 100644
--- a/xml/chapter4/section1/subsection4.xml
+++ b/xml/chapter4/section1/subsection4.xml
@@ -671,7 +671,7 @@ function driver_loop(env) {
     } else {
         const program = parse(input);
         const locals = scan_out_declarations(program);
-        const unassigneds = map(x => unassigned, locals);
+        const unassigneds = list_of_unassigned(locals);
         const program_env = extend_environment(locals, unassigneds, env);
         const output = evaluate(program, program_env);
         user_print(output_prompt, output);
@@ -692,7 +692,7 @@ function driver_loop(env) {
                 input_prompt + "\n" + input + "\n");
         const program = parse(input);
         const locals = scan_out_declarations(program);
-        const unassigneds = map(x => unassigned, locals);
+        const unassigneds = list_of_unassigned(locals);
         const program_env = extend_environment(locals, unassigneds, env);
         const output = evaluate(program, program_env);
         user_print(output_prompt, output);
diff --git a/xml/chapter4/section1/subsection6.xml b/xml/chapter4/section1/subsection6.xml
index 259672bf6..6da4f8ea1 100644
--- a/xml/chapter4/section1/subsection6.xml
+++ b/xml/chapter4/section1/subsection6.xml
@@ -167,9 +167,9 @@
 	Our environment model of evaluation
 	(section<SPACE/><REF NAME="sec:env-internal-def"/>)
 	and our metacircular evaluator
-	(section<SPACE/><REF NAME="sec:core-of-evaluator"/>) evaluate function
-	bodies and blocks by extending an environment with bindings for the
-	local names that occur in the body of the function or block. Initially,
+	(section<SPACE/><REF NAME="sec:core-of-evaluator"/>) evaluate 
+	blocks by extending an environment with bindings for the
+	local names that occur in the body of the block. Initially,
 	the names refer to the special value
 	<LATEXINLINE>$\textit{unassigned}$</LATEXINLINE>, but evaluation of the
 	declaration statements assign them to their proper values. Correct
@@ -208,7 +208,7 @@ function f(x) {
 	should refer to the function <JAVASCRIPTINLINE>is_odd</JAVASCRIPTINLINE>
 	that is declared after <JAVASCRIPTINLINE>is_even</JAVASCRIPTINLINE>.
 	The scope of the name <JAVASCRIPTINLINE>is_odd</JAVASCRIPTINLINE> is the
-	entire body of <SCHEMEINLINE>f</SCHEMEINLINE>, not just the portion of
+	body block of <SCHEMEINLINE>f</SCHEMEINLINE>, not just the portion of
 	the body of <SCHEMEINLINE>f</SCHEMEINLINE> starting at the point where
 	the declaration of <JAVASCRIPTINLINE>is_odd</JAVASCRIPTINLINE>
 	occurs. Indeed, when we consider that
@@ -221,19 +221,20 @@ function f(x) {
 	<JAVASCRIPTINLINE>is_even</JAVASCRIPTINLINE> and
 	<JAVASCRIPTINLINE>is_odd</JAVASCRIPTINLINE>
 	were being added to the environment simultaneously. More generally, in
-	block structure, the scope of a local name is the entire function
-	body in which the declaration is evaluated. 
+	block structure, the scope of a local name is the entire block
+	in which the declaration is evaluated.
       </TEXT>
       <TEXT>
-	This is achieved in section<SPACE/><REF NAME="sec:core-of-evaluator"/> by
-	the function <JAVASCRIPTINLINE>scan_out_declarations</JAVASCRIPTINLINE>,
-	and binding them to the value
-	<JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE>, whenever the function,
-	here <JAVASCRIPTINLINE>f</JAVASCRIPTINLINE>, is applied. We can make
-	this treatment of local names explicit by transforming them into
+	The evaluator in section<SPACE/><REF NAME="sec:core-of-evaluator"/>
+	finds all locally declared names of a block using
+	<JAVASCRIPTINLINE>scan_out_declarations</JAVASCRIPTINLINE>,
+	and binds them to the value
+	<JAVASCRIPTINLINE>unassigned</JAVASCRIPTINLINE>, whenever the block is
+	evaluated. For lambda expressions with local declarations, we can achieve
+	the same effect by transforming their bodies into
 	immediately invoked lambda expressions
-	(see section<SPACE/><REF NAME="sec:env-local-state"/>). For example, the
-	lambda expression
+	(see section<SPACE/><REF NAME="sec:env-local-state"/>). For example,
+	the lambda expression
 	<SNIPPET EVAL="no" LATEX="yes">
 	  <JAVASCRIPT>
 ($\textit{vars}$) => {
@@ -256,9 +257,7 @@ function f(x) {
 	  </JAVASCRIPT>
 	</SNIPPET>
 	where <SCHEMEINLINE>unassigned</SCHEMEINLINE>
-	is as defined in section<SPACE/><REF NAME="sec:eval-data-structures"/>,
-	which causes looking up a name to signal an error if an attempt is made
-	to use the value of the not-yet-assigned name.
+	is as defined in section<SPACE/><REF NAME="sec:eval-data-structures"/>.
       </TEXT>
 
       <TEXT>
@@ -274,6 +273,7 @@ function f(x) {
   </SPLIT>
 
   <EXERCISE>
+	<LABEL NAME="ex:internal-defs"/>
     <SPLIT>
       <SCHEME>
 	In this exercise we implement the method just described for interpreting
@@ -302,11 +302,11 @@ function f(x) {
 	    Which place is better? Why?
 	  </LI>
 	</OL>
-	<LABEL NAME="ex:internal-defs_scheme"/>
       </SCHEME>
       <JAVASCRIPT>
 	In this exercise we implement the method just described for interpreting
-	internal declarations as syntactic sugar for immediately invoked
+	internal declarations of lambda expressions
+	as syntactic sugar for immediately invoked
 	functions that carry out assignments.
 	<OL>
 	  <!--  \indcode{lookup-variable-value}[for scanned-out definitions] -->
@@ -324,19 +324,15 @@ function f(x) {
 	    <!--  \indcode{scan-out-defines} -->
 	    Write a function
 	    <JAVASCRIPTINLINE>transform_lambda</JAVASCRIPTINLINE>
-	    that transforms any lambda expression as shown above. Analogously,
-	    write a function <JAVASCRIPTINLINE>transform_block</JAVASCRIPTINLINE>
-	    that transforms any block in a similar manner.
+	    that transforms any lambda expression as shown above.
 	  </LI>
 	  <LI>
-	    Install <JAVASCRIPTINLINE>transform_lambda</JAVASCRIPTINLINE> and
-	    <JAVASCRIPTINLINE>transform_block</JAVASCRIPTINLINE>
+	    Install <JAVASCRIPTINLINE>transform_lambda</JAVASCRIPTINLINE>
 	    in the interpreter by modifying the function 
 	    <JAVASCRIPTINLINE>evaluate</JAVASCRIPTINLINE>
 	    in an appropriate way.
 	  </LI>
 	</OL>
-	<LABEL NAME="ex:internal-defs"/>
       </JAVASCRIPT>
     </SPLIT>
   </EXERCISE>
@@ -366,7 +362,7 @@ function f(x) {
                           v = b;
                           $\textit{statements}$
 		      })($e_1$, $e_2$);
-           })("*unassigned*", "*unassigned*");
+           })(unassigned, unassigned);
 }
 	  </JAVASCRIPT>
 	</SNIPPET>
@@ -433,34 +429,22 @@ function solve(f, y0, dt) {
     <JAVASCRIPT>
       <EXERCISE>
 	<LABEL NAME="ex:add_binding_to_frame"/>	
-	Our implementation of lambda expressions and blocks in
+	Our implementation of blocks in
 	section<SPACE/><REF NAME="sec:core-of-evaluator"/> imposes a
-	runtime burden on every function application: It needs to scan
-	the function body for locally declared names. We shall devise
-	a simpler mechanism in this exercise. In it, we fall back on
-	the penultimate specification of the environment model of
-	function application, given in
-	section<SPACE/><REF NAME="sec:env-model-rules"/>. Recall that
-	in this specification, a  function object is applied to a set of
-	arguments by constructing a frame, in which we create variable bindings
-	of the parameters of the function to the arguments of the call, and then
-	evaluating the body of the function in the context of the new
-	environment constructed. (The ultimate specification adds
-	bindings for the local names, and is given in
-	section<SPACE/><REF NAME="sec:env-internal-def"/>.) Using the
-	penultimate specification, we can achieve the desired result in
-	many cases by changing the evaluation of constant and variable
+	runtime burden: It needs to scan
+	the body of the block for locally declared names. We shall devise
+	a simpler mechanism in this exercise. We can achieve the desired result
+	in many cases by changing the evaluation of constant and variable
 	declaration such that they force into the innermost
 	frame of the given environment a binding of the declared name to
 	the result of evaluating the expression on the right hand side of the
 	declaration.
 	<UL>
 	  <LI>
-	    Simplify the declaration of
-	    <JAVASCRIPTINLINE>apply</JAVASCRIPTINLINE> in
-	    section<SPACE/><REF NAME="sec:core-of-evaluator"/> to adhere
-	    to the penultimate specification of function application, given in
-	    section<SPACE/><REF NAME="sec:env-model-rules"/>.
+	    Simplify the declaration of 
+	    <JAVASCRIPTINLINE>eval_block</JAVASCRIPTINLINE> in
+	    section<SPACE/><REF NAME="sec:core-of-evaluator"/> to 
+	    ignore local declarations.
 	  </LI>
 	  <LI>
 	    Declare a function
@@ -483,6 +467,11 @@ add_binding_to_frame($\textit{name}$, $\textit{value}$, $\textit{frame}$)
 	    <JAVASCRIPTINLINE>add_binding_to_frame</JAVASCRIPTINLINE> instead of
 	    <JAVASCRIPTINLINE>set_name_value</JAVASCRIPTINLINE>.
 	  </LI>
+	  <LI>
+	    Can you find programs that behave differently with this treatment
+	    of local declarations, compared to the implementation
+	    in section<SPACE/><REF NAME="sec:core-of-evaluator"/>?
+	  </LI>
 	</UL>
       </EXERCISE>
     </JAVASCRIPT>
@@ -510,7 +499,7 @@ add_binding_to_frame($\textit{name}$, $\textit{value}$, $\textit{frame}$)
 	the simultaneous scope rule for internal procedure definitions,	and that
 	it is unreasonable to treat procedure names differently from other names.
 	Thus, she argues for the mechanism implemented in
-	exercise<SPACE/><REF NAME="ex:internal-defs_scheme"/>. This would lead to
+	exercise<SPACE/><REF NAME="ex:internal-defs"/>. This would lead to
 	<SCHEMEINLINE>a</SCHEMEINLINE> being unassigned at the time that the
 	value for <SCHEMEINLINE>b</SCHEMEINLINE> is to be computed.  Hence, in
 	Alyssa<APOS/>s view the procedure should produce an error.  Eva has a
@@ -534,17 +523,19 @@ add_binding_to_frame($\textit{name}$, $\textit{value}$, $\textit{frame}$)
       </SCHEME>
       <JAVASCRIPT>
 	Draw diagrams of the environment in effect when evaluating the
-	<LATEXINLINE>$\textit{statement}$</LATEXINLINE> in the
+	<LATEXINLINE>$\textit{statements}$</LATEXINLINE> in the
 	function in the text, comparing how this will be structured when
 	declarations are interpreted sequentially as described in
 	exercise<SPACE/><REF NAME="ex:add_binding_to_frame"/>
-	with how it is structured if declarations are scanned out as described in
-	section<SPACE/><SPACE/><REF NAME="sec:core-of-evaluator"/>.
-	Why is there an extra frame in the latter case?  Explain why this
-	difference in environment structure can never make a difference in the
-	behavior of a correct program.  Design a way to make the interpreter
-	implement the <QUOTE>simultaneous</QUOTE> scope rule for internal 
-	declarations without constructing the extra frame.
+	with how it is structured if declarations are scanned out as described
+	in section<SPACE/><SPACE/><REF NAME="sec:core-of-evaluator"/>.
+	Why is there an extra frame in the latter case?
+	JavaScript forbids the re-declaration of parameters
+	as local names in the body block of any function. With this restriction,
+	can you achieve the scoping for local names
+	in lambda expressions of 
+	section<SPACE/><SPACE/><REF NAME="sec:core-of-evaluator"/>,
+	without constructing the extra frame?
       </JAVASCRIPT>
     </SPLIT>
   </EXERCISE>
diff --git a/xml/chapter4/section1/subsection7.xml b/xml/chapter4/section1/subsection7.xml
index 1b50610ae..a681a1e4a 100644
--- a/xml/chapter4/section1/subsection7.xml
+++ b/xml/chapter4/section1/subsection7.xml
@@ -198,6 +198,8 @@ analyze(parse("{ const x = 1; x + 1; }"))
     </SNIPPET>
     <SNIPPET>
       <NAME>analyze</NAME>
+      <REQUIRES>headline_4_1_1</REQUIRES>
+      <REQUIRES>list_of_unassigned</REQUIRES>
       <REQUIRES>functions_4_1_2</REQUIRES>
       <REQUIRES>functions_4_1_3</REQUIRES>
       <REQUIRES>functions_4_1_4</REQUIRES>
@@ -535,15 +537,6 @@ function analyze_conditional_expression(stmt) {
       </JAVASCRIPT>
     </SPLITINLINE>
     may be applied many times.
-    <SPLITINLINE>
-      <JAVASCRIPT>
-	The scanning-out of local declarations is also only
-	done once, and their bindings to the
-	<LATEXINLINE>$\textit{unassigned}$</LATEXINLINE> value are
-	installed in the environment of the function object, once
-	the execution function of the lambda expression is called.
-      </JAVASCRIPT>
-    </SPLITINLINE>
     <SNIPPET HIDE="yes">
       <NAME>analyze_lambda_example</NAME>
       <REQUIRES>analyze</REQUIRES>
@@ -569,12 +562,9 @@ list_ref(analyze_lambda(parse("x => x;"))
 function analyze_lambda(stmt) {
     const parameters = lambda_parameters(stmt);
     const body = lambda_body(stmt);
-    const locals = scan_out_declarations(body);
-    const unassigneds = map(_ => unassigned, locals);
     const bfun = analyze(body);
     return env =>
-           make_function(parameters, bfun,
-             extend_environment(locals, unassigneds, env));
+           make_function(parameters, bfun, env);
 }
       </JAVASCRIPT>
     </SNIPPET>
@@ -677,79 +667,93 @@ function analyze_sequence(stmts) {
     </SNIPPET>
   </TEXT>
 
-
-  <TEXT>
-    For return statements, we analyze the return expression and
-    apply the resulting execution function in the execution function
-    for the return statement.
-    <SNIPPET HIDE="yes">
-      <NAME>analyze_return_statement_example</NAME>
-      <REQUIRES>analyze</REQUIRES>
-      <JAVASCRIPT>
+  <SPLIT>
+    <SCHEME>
+    </SCHEME>
+    <JAVASCRIPT>
+      <TEXT>
+	For return statements, we analyze the return expression and
+	apply the resulting execution function in the execution function
+	for the return statement.
+	<SNIPPET HIDE="yes">
+	  <NAME>analyze_return_statement_example</NAME>
+	  <REQUIRES>analyze</REQUIRES>
+	  <JAVASCRIPT>
 analyze_return_statement(list_ref(parse("() => x + 1;"), 2))
    (extend_environment(list("x"), list(6), the_global_environment));
-      </JAVASCRIPT>
-    </SNIPPET>
-    <SNIPPET>
-      <NAME>analyze_return_statement</NAME>
-      <EXAMPLE>analyze_return_statement_example</EXAMPLE>
-      <EXPECTED>[ 'return_value', [ 7, null ] ]</EXPECTED>
-      <JAVASCRIPT>
+	  </JAVASCRIPT>
+	</SNIPPET>
+	<SNIPPET>
+	  <NAME>analyze_return_statement</NAME>
+	  <EXAMPLE>analyze_return_statement_example</EXAMPLE>
+	  <EXPECTED>[ 'return_value', [ 7, null ] ]</EXPECTED>
+	  <JAVASCRIPT>
 function analyze_return_statement(stmt) {
     const rfun = analyze(return_expression(stmt));
     return env => make_return_value(rfun(env));
 }
-      </JAVASCRIPT>
-    </SNIPPET>
-  </TEXT>
+	  </JAVASCRIPT>
+	</SNIPPET>
+      </TEXT>
 
-  <TEXT>
-    Just like the bodies of lambda expressions, the bodies of
-    blocks are scanned only once for local declarations, and
-    their bindings are installed in the environment, once
-    the execution function for the block is called.
-    <SNIPPET HIDE="yes">
-      <NAME>analyze_block_example</NAME>
-      <REQUIRES>analyze</REQUIRES>
-      <JAVASCRIPT>
+      <TEXT>
+	The bodies of
+	blocks are scanned only once for local declarations, and
+	their bindings are installed in the environment, once
+	the execution function for the block is called.
+	<SNIPPET HIDE="yes">
+	  <NAME>analyze_block_example</NAME>
+	  <REQUIRES>analyze</REQUIRES>
+	  <JAVASCRIPT>
 analyze_block(parse("{ const x = 4; x; }"))
    (the_global_environment);
-      </JAVASCRIPT>
-    </SNIPPET>
-    <SNIPPET>
-      <NAME>analyze_block</NAME>
-      <EXAMPLE>analyze_block_example</EXAMPLE>
-      <EXPECTED>4</EXPECTED>
-      <JAVASCRIPT>
+	  </JAVASCRIPT>
+	</SNIPPET>
+	<SNIPPET>
+	  <NAME>analyze_block</NAME>
+	  <REQUIRES>list_of_unassigned</REQUIRES>
+	  <EXAMPLE>analyze_block_example</EXAMPLE>
+	  <EXPECTED>4</EXPECTED>
+	  <JAVASCRIPT>
 function analyze_block(stmt) {
     const body = block_body(stmt);
     const locals = scan_out_declarations(body);	    
-    const unassigneds = map(_ => unassigned, locals);
+    const unassigneds = list_of_unassigned(locals);
     const bfun = analyze(body);
     return env => bfun(extend_environment(locals, unassigneds, env));
 }
-      </JAVASCRIPT>
-    </SNIPPET>
-  </TEXT>
-  
+	  </JAVASCRIPT>
+	</SNIPPET>
+      </TEXT>
+    </JAVASCRIPT>
+  </SPLIT>
   <TEXT>
-    To analyze an application, we analyze the operator and operands and
-    construct an execution
+    To analyze an application, we analyze the
     <SPLITINLINE>
-      <SCHEME>procedure</SCHEME>
-      <JAVASCRIPT>function</JAVASCRIPT>
+      <SCHEME>operator and operands</SCHEME>
+      <JAVASCRIPT>function expression and arguments</JAVASCRIPT>
     </SPLITINLINE>
-    that calls the operator execution
+    and construct an execution
     <SPLITINLINE>
       <SCHEME>procedure</SCHEME>
       <JAVASCRIPT>function</JAVASCRIPT>
     </SPLITINLINE>
+    that calls the
+    <SPLITINLINE>
+      <SCHEME>operator execution function</SCHEME>
+      <JAVASCRIPT>execution function of the function expression</JAVASCRIPT>
+    </SPLITINLINE>
     (to obtain the actual
     <SPLITINLINE>
       <SCHEME>procedure</SCHEME>
       <JAVASCRIPT>function</JAVASCRIPT>
     </SPLITINLINE>
-    to be applied) and the operand execution
+    to be applied) and the
+    <SPLITINLINE>
+      <SCHEME>operand</SCHEME>
+      <JAVASCRIPT>argument</JAVASCRIPT>
+    </SPLITINLINE>
+    execution
     <SPLITINLINE>
       <SCHEME>procedures</SCHEME>
       <JAVASCRIPT>functions</JAVASCRIPT>
@@ -883,20 +887,8 @@ function execute_application(fun, args) {
     <JAVASCRIPT>
 	<INDEX>analyzing evaluator
 	<SUBINDEX>conditional statements</SUBINDEX></INDEX>
-	Eva Lu Ator ponders over the treatment of locally
-	declared names in the function
-	<JAVASCRIPTINLINE>analyze_lambda</JAVASCRIPTINLINE>, drawing
-	environment model diagrams. Alyssa P. Hacker notices
-	and asks her what's wrong. Eva complains that she is getting
-	different diagrams than the ones obtained from following
-	the evaluator in section<SPACE/><REF NAME="sec:core-of-evaluator"/>.
-	Eva agrees, but says: <QUOTE>Don't worry. Any program that runs properly
-	in the original evaluator will properly in the syntactic analysis
-	evaluator.</QUOTE> Is Eva right? Try to draw the diagrams that Eva
-	is talking about. How about the other way around: Are there programs
-	that run <QUOTE>properly</QUOTE> in the syntactic analysis evaluator,
-	but not in the original one? If yes, can you change the syntactic
-	analysis evaluator such that it behaves exactly like the original one.
+	Extend the evaluator in this section to support while loops.
+	(See exercise<SPACE/><REF NAME="ex:while_loop"/>.)
     </JAVASCRIPT>
     </SPLIT>
   </EXERCISE>
@@ -1051,7 +1043,7 @@ function analyze_sequence(stmts) {
 function parse_and_evaluate(input) {
     const program = parse(input);
     const locals = scan_out_declarations(program);
-    const unassigneds = map(x => unassigned, locals);
+    const unassigneds = list_of_unassigned(locals);
     const program_env = extend_environment(locals, unassigneds,
                                        the_global_environment);
     return evaluate(program, program_env);
diff --git a/xml/chapter4/section2/subsection2.xml b/xml/chapter4/section2/subsection2.xml
index f579d5c2e..5c3ed6d70 100644
--- a/xml/chapter4/section2/subsection2.xml
+++ b/xml/chapter4/section2/subsection2.xml
@@ -383,12 +383,8 @@ function apply(fun, args, env) {
                   map(arg => actual_value(arg, env), args));
    } else if (is_compound_function(fun)) {
       const body = function_body(fun);
-      const locals = scan_out_declarations(body);
-      const symbols = append(function_parameters(fun), locals);
-      const unassigneds = map(_ => unassigned, locals);
-                            // following line changed
-      const values = append(map(arg => delay_it(arg, env), args),
-                            unassigneds);
+      const symbols = function_parameters(fun);
+      const values = map(arg => delay_it(arg, env), args);
       const result = evaluate(body,
                        extend_environment(symbols, values,
                          function_environment(fun)));
@@ -610,7 +606,7 @@ function driver_loop(env) {
     } else {
         const program = parse(input);
         const locals = scan_out_declarations(program);
-        const unassigneds = map(x => unassigned, locals);
+        const unassigneds = list_of_unassigned(locals);
         const program_env = extend_environment(locals, unassigneds, env);
         const output = actual_value(program, program_env);
         user_print(output_prompt, output);
@@ -631,7 +627,7 @@ function driver_loop(env) {
                 input_prompt + "\n" + input + "\n");
         const program = parse(input);
         const locals = scan_out_declarations(program);
-        const unassigneds = map(x => unassigned, locals);
+        const unassigneds = list_of_unassigned(locals);
         const program_env = extend_environment(locals, unassigneds, env);
         const output = actual_value(program, program_env);
         user_print(output_prompt, output);
@@ -1506,7 +1502,7 @@ function f(a, b, c, d) {
 function parse_and_evaluate(input) {
     const program = parse(input);
     const locals = scan_out_declarations(program);
-    const unassigneds = map(x => unassigned, locals);
+    const unassigneds = list_of_unassigned(locals);
     const program_env = extend_environment(locals, unassigneds,
                                        the_global_environment);
     return actual_value(program, program_env);
diff --git a/xml/chapter4/section3/subsection3.xml b/xml/chapter4/section3/subsection3.xml
index fffd5c0e8..34062ff82 100644
--- a/xml/chapter4/section3/subsection3.xml
+++ b/xml/chapter4/section3/subsection3.xml
@@ -639,12 +639,9 @@ function analyze_name(stmt) {
 function analyze_lambda(stmt) {
     const parameters = lambda_parameters(stmt);
     const body = lambda_body(stmt);
-    const locals = scan_out_declarations(body);
-    const unassigneds = map(_ => unassigned, locals);
     const bfun = analyze(body);
     return (env, succeed, fail) =>
-           succeed(make_function(parameters, bfun,
-                     extend_environment(locals, unassigneds, env)),
+           succeed(make_function(parameters, bfun, env),
                    fail);
 }
       </JAVASCRIPT>
@@ -1067,12 +1064,13 @@ function analyze_return_statement(stmt) {
 	failure continuations.
 	<SNIPPET>
 	  <NAME>analyze_block_amb</NAME>
+	  <REQUIRES>list_of_unassigned</REQUIRES>
 	  <EXAMPLE>all_solutions_test_4</EXAMPLE>
 	  <JAVASCRIPT>
 function analyze_block(stmt) {
     const body = block_body(stmt);
     const locals = scan_out_declarations(body);
-    const unassigneds = map(_ => unassigned, locals);
+    const unassigneds = list_of_unassigned(locals);
     const bfun = analyze(body);
     return (env, succeed, fail) =>
            bfun(extend_environment(locals, unassigneds, env),
diff --git a/xml/chapter4/section4/subsection4.xml b/xml/chapter4/section4/subsection4.xml
index e03a8c6c4..e55b14bd5 100644
--- a/xml/chapter4/section4/subsection4.xml
+++ b/xml/chapter4/section4/subsection4.xml
@@ -3151,11 +3151,11 @@ function pretty(string, args, arg_pretty) {
 function pretty_term(arg) {
     return is_null(arg)
         ? "null"
-        : is_list(arg) &amp;&amp;
-	  (is_null(tail(arg)) || head(tail(arg)) !== "?")
-        ? (head(arg) === "?"
-           ? contract_question_mark(arg)
-	   : pretty("list", arg, pretty_term))
+        : is_list(arg) &amp;&amp; head(arg) === "?"
+	? contract_question_mark(arg)
+	: is_list(arg) &amp;&amp; 
+          (is_null(tail(arg)) || head(tail(arg)) !== "?")
+        ? pretty("list", arg, pretty_term))
         : is_pair(arg)
         ? pretty("pair", list(head(arg), tail(arg)), pretty_term)
 	: is_string(arg)
diff --git a/xml/chapter5/chapter5.xml b/xml/chapter5/chapter5.xml
index 5eef23352..a6998675d 100644
--- a/xml/chapter5/chapter5.xml
+++ b/xml/chapter5/chapter5.xml
@@ -26,7 +26,7 @@
     % 2/24/96 use smalltt to make some stuff fit nicely in 5.2
     % 2/23/96 use Stabular instead of point-size changes
     % 2/22/96 new spec for epigraph
-    %2/19/96 change exp-iter - -&gt; expt-iter
+    % 2/19/96 change exp-iter - -&gt; expt-iter
   </HISTORY>
 
   <EPIGRAPH>
diff --git a/xml/chapter5/section1/section1.xml b/xml/chapter5/section1/section1.xml
index 05304a110..7b37c8266 100644
--- a/xml/chapter5/section1/section1.xml
+++ b/xml/chapter5/section1/section1.xml
@@ -1,156 +1,180 @@
-  <SECTION>
-    <NAME>Designing Register Machines</NAME>
-
-    <SECTIONCONTENT/>
-
-    <LABEL NAME="sec:designing-register-machines"/>
-    <INDEX>register machine<SUBINDEX>design of|(</SUBINDEX></INDEX>
-    <INDEX>register machine<SUBINDEX>data paths|(</SUBINDEX></INDEX>
-    <INDEX>register machine<SUBINDEX>controller|(</SUBINDEX></INDEX>
-    <INDEX>data paths for register machine|(</INDEX>
-    <INDEX>controller for register machine|(</INDEX>
-    <INDEX>operation<SUBINDEX>in register machine|(</SUBINDEX></INDEX>
-
-    <TEXT>
-      To design a register machine, we must design its <EM>data paths</EM>
-      (registers and operations) and the <EM>controller</EM> that sequences
-      these operations.  To illustrate the design of a simple register
-      machine, let us examine Euclid<APOS/>s Algorithm, which is used to compute
-      <!--  \indcode{gcd}[register machine for|(] -->
-      the greatest common divisor (GCD) of two integers.  As we saw in
-      <INDEX>Euclid<APOS/>s Algorithm</INDEX>
-      section<SPACE/><REF NAME="sec:gcd"/>, Euclid<APOS/>s Algorithm can be carried out by an iterative
-      process, as specified by the following
-      <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>:
-
-      <SNIPPET>
-  <SCHEME>
+<SECTION>
+  <NAME>Designing Register Machines</NAME>
+
+  <SECTIONCONTENT/>
+
+  <LABEL NAME="sec:designing-register-machines"/>
+  <INDEX>register machine<SUBINDEX>design of|(</SUBINDEX></INDEX>
+  <INDEX>register machine<SUBINDEX>data paths|(</SUBINDEX></INDEX>
+  <INDEX>register machine<SUBINDEX>controller|(</SUBINDEX></INDEX>
+  <INDEX>data paths for register machine|(</INDEX>
+  <INDEX>controller for register machine|(</INDEX>
+  <INDEX>operation<SUBINDEX>in register machine|(</SUBINDEX></INDEX>
+
+  <TEXT>
+    To design a register machine, we must design its <EM>data paths</EM>
+    (registers and operations) and the <EM>controller</EM> that sequences
+    these operations.  To illustrate the design of a simple register
+    machine, let us examine Euclid<APOS/>s Algorithm, which is used to compute
+    <!--  \indcode{gcd}[register machine for|(] -->
+    the greatest common divisor (GCD) of two integers.  As we saw in
+    <INDEX>Euclid<APOS/>s Algorithm</INDEX>
+    section<SPACE/><REF NAME="sec:gcd"/>, Euclid<APOS/>s Algorithm can be
+    carried out by an iterative process, as specified by the following
+    <SPLITINLINE>
+      <SCHEME>procedure:</SCHEME>
+      <JAVASCRIPT>function:</JAVASCRIPT>
+      </SPLITINLINE>
+    <SNIPPET>
+      <EXAMPLE>gcd_example</EXAMPLE>	
+      <SCHEME>
     (define (gcd a b)
     (if (= b 0)
     a
     (gcd b (remainder a b))))
-  </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function gcd(a, b) {
     return b === 0 ? a : gcd(b, a % b);
 }
-  </JAVASCRIPT>
-      </SNIPPET>
-    </TEXT>
-
-    <TEXT>
-      A machine to carry out this algorithm must keep track of two numbers,
-      <LATEXINLINE>$a$</LATEXINLINE> and <LATEXINLINE>$b$</LATEXINLINE>, so let us assume that these numbers are stored in two
-      registers with those names.  The basic operations required are testing
-      whether the contents of register <SCHEMEINLINE>b</SCHEMEINLINE> is zero and computing the
-      remainder of the contents of register <SCHEMEINLINE>a</SCHEMEINLINE> divided by the contents
-      of register <SCHEMEINLINE>b</SCHEMEINLINE>.  The remainder operation is a complex process,
-      but assume for the moment that we have a primitive device that
-      computes remainders.  On each cycle of the GCD algorithm, the contents
-      of register <SCHEMEINLINE>a</SCHEMEINLINE> must be replaced by the contents of register <SCHEMEINLINE>b</SCHEMEINLINE>, and the contents of <SCHEMEINLINE>b</SCHEMEINLINE> must be replaced by the remainder of
-      the old contents of <SCHEMEINLINE>a</SCHEMEINLINE> divided by the old contents of <SCHEMEINLINE>b</SCHEMEINLINE>.
-      It would be convenient if these replacements could be done
-      simultaneously, but in our model of register machines we will assume
-      that only one register can be assigned a new value at each step.  To
-      accomplish the replacements, our machine will use a third
-      <QUOTE>temporary</QUOTE> register, which we call <SCHEMEINLINE>t</SCHEMEINLINE>.  (First the remainder
-      will be placed in <SCHEMEINLINE>t</SCHEMEINLINE>, then the contents of <SCHEMEINLINE>b</SCHEMEINLINE> will be placed
-      in <SCHEMEINLINE>a</SCHEMEINLINE>, and finally the remainder stored in <SCHEMEINLINE>t</SCHEMEINLINE> will be placed
-      in <SCHEMEINLINE>b</SCHEMEINLINE>.)
-    </TEXT>
-
-    <TEXT>
-      <INDEX>data paths for register machine<SUBINDEX>data-path diagram</SUBINDEX></INDEX>
-      <INDEX>register machine<SUBINDEX>data-path diagram</SUBINDEX></INDEX>
-      We can illustrate the registers and operations required for this
-      machine by using the data-path diagram shown in
-      figure<SPACE/><REF NAME="fig:gcd-machine"/>.  In this
-      diagram, the registers (<SCHEMEINLINE>a</SCHEMEINLINE>, <SCHEMEINLINE>b</SCHEMEINLINE>, and <SCHEMEINLINE>t</SCHEMEINLINE>) are represented
-      by rectangles.  Each way to assign a value to a register is
-      indicated by an arrow with an <SCHEMEINLINE>X</SCHEMEINLINE> behind the head, pointing from
-      the source of data to the register.  We can think of the <SCHEMEINLINE>X</SCHEMEINLINE> as a
-      button that, when pushed, allows the value at the source to <QUOTE>flow</QUOTE>
-      into the designated register.  The label next to each button is the
-      name we will use to refer to the button.  The names are arbitrary, and
-      can be chosen to have mnemonic value (for example, <SCHEMEINLINE>a&lt;-b</SCHEMEINLINE> denotes
-      pushing the button that assigns the contents of register <SCHEMEINLINE>b</SCHEMEINLINE> to
-      register <SCHEMEINLINE>a</SCHEMEINLINE>).  The source of data for a register can be another
-      register (as in the <SCHEMEINLINE>a&lt;-b</SCHEMEINLINE> assignment), an operation result (as in
-      the <SCHEMEINLINE>t&lt;-r</SCHEMEINLINE> assignment), or a constant (a built-in value that
-      cannot be changed, represented in a data-path diagram by a triangle
-      containing the constant).
-    </TEXT>
-
-    <TEXT>
-      An operation that computes a value from constants and the contents
-      of registers is represented in a data-path diagram by a trapezoid
-      containing a name for the operation.  For example, the box marked <SCHEMEINLINE>rem</SCHEMEINLINE> in figure<SPACE/><REF NAME="fig:gcd-machine"/> represents an
-      operation that computes the remainder of the contents of the
-      registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE> to which it is attached.  Arrows
-      (without buttons) point from the input registers and constants to the
-      box, and arrows connect the operation<APOS/>s output value to registers.
-      A test is represented by a circle containing a name for the test.  For
-      example, our GCD machine has an operation that
-      tests whether the contents of register
-      <SCHEMEINLINE>b</SCHEMEINLINE> is zero.  A test also has arrows from its input
-      <INDEX>test operation in register machine</INDEX>
-      <INDEX>register machine<SUBINDEX>test operation</SUBINDEX></INDEX>
-      registers and constants, but it has no output
-      arrows; its value is used by the controller rather than by the data
-      paths.  Overall, the data-path diagram shows the registers and
-      operations that are required for the machine and how they must be
-      connected.  If we view the arrows as wires and the <SCHEMEINLINE>X</SCHEMEINLINE> buttons as
-      switches, the data-path diagram is very like the wiring diagram for a
-      machine that could be constructed from electrical components.
-      
-      <FIGURE>
-	<FIGURE src="img_original/Fig5.1a.std.svg"/>
-        <LABEL NAME="fig:gcd-machine"/>
-        <CAPTION>Data paths for a GCD machine. </CAPTION>
-      </FIGURE>
-    </TEXT>
-
-    <TEXT>
-      <INDEX>register machine<SUBINDEX>controller diagram</SUBINDEX></INDEX>
-      <INDEX>controller for register machine<SUBINDEX>controller diagram</SUBINDEX></INDEX>
-      In order for the data paths to actually compute GCDs, the buttons must
-      be pushed in the correct sequence.  We will describe this sequence in
-      terms of a controller diagram, as illustrated in
-      figure<SPACE/><REF NAME="fig:gcd-controller"/>.  The elements of the controller
-      diagram indicate how the
-      data-path components should be operated.  The rectangular boxes in the
-      controller diagram identify data-path buttons to be pushed, and the
-      arrows describe the sequencing from one step to the next.  The diamond
-      in the diagram represents a decision.  One of the two sequencing
-      arrows will be followed, depending on the value of the data-path test
-      identified in the diamond.  We can interpret the controller in terms
-      of a physical analogy: Think of the diagram as a maze in which a
-      marble is rolling.  When the marble rolls into a box, it pushes the
-      data-path button that is named by the box.  When the marble rolls into
-      a decision node (such as the test for <SCHEMEINLINE>b</SCHEMEINLINE><LATEXINLINE>$\, =0$</LATEXINLINE>), it leaves the
-      node on the path determined by the result of the indicated test.
-      Taken together, the data paths and the controller completely describe
-      a machine for computing GCDs.  We start the controller (the rolling
-      marble) at the place marked <SCHEMEINLINE>start</SCHEMEINLINE>, after placing numbers in
-      registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE>.  When the controller reaches <SCHEMEINLINE>done</SCHEMEINLINE>, we will find the value of the GCD in register <SCHEMEINLINE>a</SCHEMEINLINE>.
-      <!--  \indcode{gcd}[register machine for|)] -->
-
-      <FIGURE>
-	<FIGURE src="img_original/Fig5.2.std.svg"/>
-        <LABEL NAME="fig:gcd-controller"/>
-        <CAPTION>Controller for a GCD machine.</CAPTION>
-      </FIGURE>
-    </TEXT>
-
-    <EXERCISE><LABEL NAME="ex:iterative-fact"/>
-      <!--  \indcode{factorial}[register machine for (iterative)] -->
-      Design a register machine to compute factorials using the iterative
-      algorithm specified by the following
-      <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  Draw data-path and
-      controller diagrams for this machine.
-
-      <SNIPPET>
-  <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    A machine to carry out this algorithm must keep track of two numbers,
+    <LATEXINLINE>$a$</LATEXINLINE> and <LATEXINLINE>$b$</LATEXINLINE>, so let
+    us assume that these numbers are stored in two registers with those names.
+    The basic operations required are testing whether the contents of register
+    <SCHEMEINLINE>b</SCHEMEINLINE> is zero and computing the remainder of the
+    contents of register <SCHEMEINLINE>a</SCHEMEINLINE> divided by the contents
+    of register <SCHEMEINLINE>b</SCHEMEINLINE>.  The remainder operation is a
+    complex process,
+    but assume for the moment that we have a primitive device that
+    computes remainders.  On each cycle of the GCD algorithm, the contents
+    of register <SCHEMEINLINE>a</SCHEMEINLINE> must be replaced by the contents
+    of register <SCHEMEINLINE>b</SCHEMEINLINE>, and the contents of
+    <SCHEMEINLINE>b</SCHEMEINLINE> must be replaced by the remainder of
+    the old contents of <SCHEMEINLINE>a</SCHEMEINLINE> divided by the old
+    contents of <SCHEMEINLINE>b</SCHEMEINLINE>. It would be convenient if these
+    replacements could be done simultaneously, but in our model of register
+    machines we will assume that only one register can be assigned a new value
+    at each step.  To accomplish the replacements, our machine will use a third
+    <QUOTE>temporary</QUOTE> register, which we call
+    <SCHEMEINLINE>t</SCHEMEINLINE>.  (First the remainder
+    will be placed in <SCHEMEINLINE>t</SCHEMEINLINE>, then the contents of
+    <SCHEMEINLINE>b</SCHEMEINLINE> will be placed in
+    <SCHEMEINLINE>a</SCHEMEINLINE>, and finally the remainder stored in
+    <SCHEMEINLINE>t</SCHEMEINLINE> will be placed in
+    <SCHEMEINLINE>b</SCHEMEINLINE>.)
+  </TEXT>
+
+  <TEXT>
+    <INDEX>data paths for register machine
+    <SUBINDEX>data-path diagram</SUBINDEX></INDEX>
+    <INDEX>register machine<SUBINDEX>data-path diagram</SUBINDEX></INDEX>
+    We can illustrate the registers and operations required for this
+    machine by using the data-path diagram shown in
+    figure<SPACE/><REF NAME="fig:gcd-machine"/>.  In this
+    diagram, the registers (<SCHEMEINLINE>a</SCHEMEINLINE>,
+    <SCHEMEINLINE>b</SCHEMEINLINE>, and <SCHEMEINLINE>t</SCHEMEINLINE>) are
+    represented by rectangles.  Each way to assign a value to a register is
+    indicated by an arrow with an <SCHEMEINLINE>X</SCHEMEINLINE> behind the
+    head, pointing from the source of data to the register.  We can think of
+    the <SCHEMEINLINE>X</SCHEMEINLINE> as a button that, when pushed, allows
+    the value at the source to <QUOTE>flow</QUOTE> into the designated register.
+    The label next to each button is the name we will use to refer to the
+    button.  The names are arbitrary, and can be chosen to have mnemonic value
+    (for example, <SCHEMEINLINE>a&lt;-b</SCHEMEINLINE> denotes pushing the
+    button that assigns the contents of register <SCHEMEINLINE>b</SCHEMEINLINE>
+    to register <SCHEMEINLINE>a</SCHEMEINLINE>).  The source of data for a
+    register can be another register (as in the
+    <SCHEMEINLINE>a&lt;-b</SCHEMEINLINE> assignment), an operation result (as in
+    the <SCHEMEINLINE>t&lt;-r</SCHEMEINLINE> assignment), or a constant
+    (a built-in value that cannot be changed, represented in a data-path
+    diagram by a triangle containing the constant).
+  </TEXT>
+
+  <TEXT>
+    An operation that computes a value from constants and the contents
+    of registers is represented in a data-path diagram by a trapezoid
+    containing a name for the operation.  For example, the box marked
+    <SCHEMEINLINE>rem</SCHEMEINLINE> in
+    figure<SPACE/><REF NAME="fig:gcd-machine"/> represents an operation that
+    computes the remainder of the contents of the registers
+    <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE> to which
+    it is attached.  Arrows (without buttons) point from the input registers and
+    constants to the box, and arrows connect the operation<APOS/>s output value
+    to registers. A test is represented by a circle containing a name for the
+    test.  For  example, our GCD machine has an operation that tests whether the
+    contents of register <SCHEMEINLINE>b</SCHEMEINLINE> is zero.  A test also
+    has arrows from its input
+    <INDEX>test operation in register machine</INDEX>
+    <INDEX>register machine<SUBINDEX>test operation</SUBINDEX></INDEX>
+    registers and constants, but it has no output
+    arrows; its value is used by the controller rather than by the data
+    paths.  Overall, the data-path diagram shows the registers and
+    operations that are required for the machine and how they must be
+    connected.  If we view the arrows as wires and the
+    <SCHEMEINLINE>X</SCHEMEINLINE> buttons as switches, the data-path diagram
+    is very like the wiring diagram for a machine that could be constructed
+    from electrical components.
+    <FIGURE>
+      <FIGURE scale_factor="3" src="img_original/Fig5.1a.std.svg"/>
+      <LABEL NAME="fig:gcd-machine"/>
+      <CAPTION>Data paths for a GCD machine. </CAPTION>
+    </FIGURE>
+  </TEXT>
+
+  <TEXT>
+    <INDEX>register machine<SUBINDEX>controller diagram</SUBINDEX></INDEX>
+    <INDEX>controller for register machine
+    <SUBINDEX>controller diagram</SUBINDEX></INDEX>
+    In order for the data paths to actually compute GCDs, the buttons must
+    be pushed in the correct sequence.  We will describe this sequence in
+    terms of a controller diagram, as illustrated in
+    figure<SPACE/><REF NAME="fig:gcd-controller"/>.  The elements of the
+    controller diagram indicate how the data-path components should be operated.
+    The rectangular boxes in the controller diagram identify data-path buttons
+    to be pushed, and the arrows describe the sequencing from one step to the
+    next.  The diamond in the diagram represents a decision.  One of the two
+    sequencing arrows will be followed, depending on the value of the data-path
+    test identified in the diamond.  We can interpret the controller in terms
+    of a physical analogy: Think of the diagram as a maze in which a marble is
+    rolling.  When the marble rolls into a box, it pushes the data-path button
+    that is named by the box.  When the marble rolls into a decision node (such
+    as the test for
+    <SCHEMEINLINE>b</SCHEMEINLINE><LATEXINLINE>$\, =0$</LATEXINLINE>), it leaves
+    the node on the path determined by the result of the indicated test.
+    Taken together, the data paths and the controller completely describe
+    a machine for computing GCDs.  We start the controller (the rolling
+    marble) at the place marked <SCHEMEINLINE>start</SCHEMEINLINE>, after
+    placing numbers in registers <SCHEMEINLINE>a</SCHEMEINLINE> and
+    <SCHEMEINLINE>b</SCHEMEINLINE>.  When the controller reaches
+    <SCHEMEINLINE>done</SCHEMEINLINE>, we will find the value of the GCD in
+    register <SCHEMEINLINE>a</SCHEMEINLINE>.
+    <!--  \indcode{gcd}[register machine for|)] -->
+    <FIGURE>
+      <FIGURE scale_factor="5" src="img_original/Fig5.2.std.svg"/>
+      <LABEL NAME="fig:gcd-controller"/>
+      <CAPTION>Controller for a GCD machine.</CAPTION>
+    </FIGURE>
+  </TEXT>
+
+  <EXERCISE>
+    <LABEL NAME="ex:iterative-fact"/>
+    <!--  \indcode{factorial}[register machine for (iterative)] -->
+    Design a register machine to compute factorials using the iterative
+    algorithm specified by the following
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+      <JAVASCRIPT>function.</JAVASCRIPT>
+    </SPLITINLINE>
+    Draw data-path and
+    controller diagrams for this machine.
+    <SNIPPET>
+      <EXAMPLE>factorial_example</EXAMPLE>
+      <SCHEME>
     (define (factorial n)
     (define (iter product counter)
     (if (&gt; counter n)
@@ -158,8 +182,8 @@ function gcd(a, b) {
           (iter (* counter product)
           (+ counter 1))))
     (iter 1 1))
-  </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function factorial(n) {
     function iter(product, counter) {
         return counter &gt; n 
@@ -169,28 +193,28 @@ function factorial(n) {
    }
    return iter(1, 1);
 }    
-  </JAVASCRIPT>
-      </SNIPPET>
-    </EXERCISE>
-    <INDEX>data paths for register machine|)</INDEX>
-    <INDEX>controller for register machine|)</INDEX>
-    <INDEX>register machine<SUBINDEX>data paths|)</SUBINDEX></INDEX>
-    <INDEX>register machine<SUBINDEX>controller|)</SUBINDEX></INDEX>
-    <INDEX>operation<SUBINDEX>in register machine|)</SUBINDEX></INDEX>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </EXERCISE>
+  <INDEX>data paths for register machine|)</INDEX>
+  <INDEX>controller for register machine|)</INDEX>
+  <INDEX>register machine<SUBINDEX>data paths|)</SUBINDEX></INDEX>
+  <INDEX>register machine<SUBINDEX>controller|)</SUBINDEX></INDEX>
+  <INDEX>operation<SUBINDEX>in register machine|)</SUBINDEX></INDEX>
 
-    <!-- Subsection 1 : A Language for Describing Register Machines -->
-    &subsection5.1.1;
+  <!-- Subsection 1 : A Language for Describing Register Machines -->
+  &subsection5.1.1;
 
-    <!-- Subsection 2 : Abstraction in Machine Design -->
-    &subsection5.1.2;
+  <!-- Subsection 2 : Abstraction in Machine Design -->
+  &subsection5.1.2;
 
-    <!-- Subsection 3 : Subroutines -->
-    &subsection5.1.3;
+  <!-- Subsection 3 : Subroutines -->
+  &subsection5.1.3;
 
-    <!-- Subsection 4 : Using a Stack to Implement Recursion -->
-    &subsection5.1.4;
+  <!-- Subsection 4 : Using a Stack to Implement Recursion -->
+  &subsection5.1.4;
 
-    <!-- Subsection 5 : Instruction Summary -->
-    &subsection5.1.5;
+  <!-- Subsection 5 : Instruction Summary -->
+  &subsection5.1.5;
 
-  </SECTION>
+</SECTION>
diff --git a/xml/chapter5/section1/subsection1.xml b/xml/chapter5/section1/subsection1.xml
index 783b84714..fbc7f5ce4 100644
--- a/xml/chapter5/section1/subsection1.xml
+++ b/xml/chapter5/section1/subsection1.xml
@@ -1,79 +1,95 @@
-    <SUBSECTION>
-      <NAME>
-  A Language for Describing Register Machines
-      </NAME>
+<SUBSECTION>
+  <NAME>
+    A Language for Describing Register Machines
+  </NAME>
 
-      <LABEL NAME="sec:register-machine-language"/>
-      <INDEX>register machine<SUBINDEX>language for describing|(</SUBINDEX></INDEX>
+  <LABEL NAME="sec:register-machine-language"/>
+  <INDEX>register machine<SUBINDEX>language for describing|(</SUBINDEX></INDEX>
 
-      <TEXT>
-  Data-path and controller diagrams are adequate for representing simple
-  machines such as GCD, but they are unwieldy for describing large
-  machines such as a <SPLITINLINE><SCHEME>Lisp</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE> interpreter.  To make it possible to deal with complex machines, we will create a language that presents, in textual
-  form, all the information given by the data-path and controller
-  diagrams.  We will start with a notation that directly mirrors the diagrams.
-      </TEXT>
-      
-      <TEXT>
-  We define the data paths of a machine by describing the registers and
-  the operations.  To describe a register, we give it a name
-  and specify the buttons that control assignment to it.  We give each
-  of these buttons a name and specify the source of the data that enters
-  the register under the button<APOS/>s control.  (The source is a register, a
-  constant, or an operation.)
-  To describe an operation, we give
-  it a name and specify its inputs (registers or constants).
-      </TEXT>
+  <TEXT>
+    Data-path and controller diagrams are adequate for representing simple
+    machines such as GCD, but they are unwieldy for describing large
+    machines such as a
+    <SPLITINLINE>
+      <SCHEME>Lisp</SCHEME>
+      <JAVASCRIPT>JavaScript</JAVASCRIPT>
+    </SPLITINLINE>
+    interpreter.  To make it possible to deal with complex machines, we will
+    create a language that presents, in textual form, all the information given
+    by the data-path and controller diagrams.  We will start with a notation
+    that directly mirrors the diagrams.
+  </TEXT>
+  
+  <TEXT>
+    We define the data paths of a machine by describing the registers and
+    the operations.  To describe a register, we give it a name
+    and specify the buttons that control assignment to it.  We give each
+    of these buttons a name and specify the source of the data that enters
+    the register under the button<APOS/>s control.  (The source is a register,
+    a constant, or an operation.) To describe an operation, we give
+    it a name and specify its inputs (registers or constants).
+  </TEXT>
 
-      <TEXT>
-  We define the controller of a machine as a sequence of 
-  <INDEX>register-machine language<SUBINDEX>instructions</SUBINDEX></INDEX>
-  <EM>
-    instructions</EM> together with 
-  <INDEX>register-machine language<SUBINDEX>label</SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>entry point</SUBINDEX></INDEX>
-  <EM>labels</EM> that identify <EM>entry
-    points</EM> in the sequence. An instruction is one of the following:
-  <UL>
-    <LI>The name of a data-path button to push to assign a value to
-      a register.  (This corresponds to a box in the controller diagram.)
+  <TEXT>
+    We define the controller of a machine as a sequence of 
+    <INDEX>register-machine language<SUBINDEX>instructions</SUBINDEX></INDEX>
+    <EM>
+      instructions</EM> together with 
+      <INDEX>register-machine language<SUBINDEX>label</SUBINDEX></INDEX>
+      <INDEX>register-machine language<SUBINDEX>entry point</SUBINDEX></INDEX>
+      <EM>labels</EM> that identify <EM>entry
+      points</EM> in the sequence. An instruction is one of the following:
+      <UL>
+	<LI>
+	  The name of a data-path button to push to assign a value to
+	  a register.  (This corresponds to a box in the controller diagram.)
+	  <INDEX>register-machine language
+	  <SUBINDEX>test@<SCHEMEINLINE>test</SCHEMEINLINE></SUBINDEX></INDEX>
+	  <!-- \indcodeplus{test}{(in register machine)}-->
+	</LI>
+	<LI>
+	  A <SCHEMEINLINE>test</SCHEMEINLINE> instruction, that performs a
+	  specified test.
+	  <INDEX>register-machine language
+	  <SUBINDEX>branch@<SCHEMEINLINE>branch</SCHEMEINLINE></SUBINDEX></INDEX>
+	  <!-- \indcodeplus{branch}{(in register machine)}-->
+	  <INDEX>register-machine language
+	  <SUBINDEX>label@<SCHEMEINLINE>label</SCHEMEINLINE></SUBINDEX></INDEX>
+	  <!-- \indcodeplus{label}{(in register machine)}-->
+	</LI>
+	<LI>
+	  A conditional branch (<SCHEMEINLINE>branch</SCHEMEINLINE> instruction)
+	  to a	location indicated by a controller label, based on the result of
+	  the previous test.  (The test and branch together correspond to a
+	  diamond in the controller diagram.)  If the test is false, the
+	  controller should continue with the next instruction in the sequence.
+	  Otherwise, the controller should continue with the instruction after
+	  the label.
+	  <INDEX>register-machine language
+	  <SUBINDEX>goto@<SCHEMEINLINE>goto</SCHEMEINLINE></SUBINDEX></INDEX>
+	  <!-- \indcodeplus{goto}{(in register machine)}-->
+	</LI>
+	<LI>
+	  An unconditional branch
+	  <SPLITINLINE>
+	    <SCHEME>(<SCHEMEINLINE>goto</SCHEMEINLINE></SCHEME>
+	    <JAVASCRIPT>(<JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT>
+	  </SPLITINLINE>
+	  instruction) naming a
+	controller label at which to continue execution.
+	</LI>
+      </UL>
+  </TEXT>
 
-      <INDEX>register-machine language<SUBINDEX>test@<SCHEMEINLINE>test</SCHEMEINLINE></SUBINDEX></INDEX>
-      <!-- \indcodeplus{test}{(in register machine)}-->
-    </LI>
-    <LI>A <SCHEMEINLINE>test</SCHEMEINLINE> instruction, that performs a specified test.
+  <TEXT>
+    The machine starts at the beginning of the controller instruction
+    sequence and stops when execution reaches the end of the sequence.
+    Except when a branch changes the flow of control, instructions are
+    executed in the order in which they are listed.
 
-      <INDEX>register-machine language<SUBINDEX>branch@<SCHEMEINLINE>branch</SCHEMEINLINE></SUBINDEX></INDEX>
-      <!-- \indcodeplus{branch}{(in register machine)}-->
-      <INDEX>register-machine language<SUBINDEX>label@<SCHEMEINLINE>label</SCHEMEINLINE></SUBINDEX></INDEX>
-      <!-- \indcodeplus{label}{(in register machine)}-->
-    </LI>
-    <LI>A conditional branch (<SCHEMEINLINE>branch</SCHEMEINLINE> instruction) to a
-      location indicated by a controller label, based on the result of the
-      previous test.  (The test and branch together correspond to a diamond
-      in the controller diagram.)  If the test is false, the controller
-      should continue with the next instruction in the sequence.  Otherwise,
-      the controller should continue with the instruction after the label.
-
-      <INDEX>register-machine language<SUBINDEX>goto@<SCHEMEINLINE>goto</SCHEMEINLINE></SUBINDEX></INDEX>
-      <!-- \indcodeplus{goto}{(in register machine)}-->
-    </LI>
-    <LI>An unconditional branch (<SPLITINLINE><SCHEME><SCHEMEINLINE>goto</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> instruction) naming a
-      controller label at which to continue execution.
-    </LI>
-
-  </UL>
-      </TEXT>
-
-      <TEXT>
-  The machine starts at the beginning of the controller instruction
-  sequence and stops when execution reaches the end of the sequence.
-  Except when a branch changes the flow of control, instructions are
-  executed in the order in which they are listed.
-
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <SCHEME>
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       (data-paths
       (registers
       ((name a)
@@ -98,8 +114,8 @@
       (b&lt;-t)                         <EM>; button push</EM>
       (goto (label test-b))          <EM>; unconditional branch</EM>
       gcd-done)                        <EM>; label</EM>
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 data_paths(
     registers(
         list(
@@ -124,63 +140,75 @@ controller(
         "t&lt;-r",                     // button push
         "a&lt;-b",                     // button push
         "b&lt;-t",                     // button push
-        go_to(label("test-b"))),     // unconditional branch
+        go_to(label("test-b"))),    // unconditional branch
     "gcd-done");                    // label
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>A specification of the GCD machine.</CAPTION>
-  <LABEL NAME="fig:gcd-machine-spec"/>
-  </FIGURE>
-      </TEXT>
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>A specification of the GCD machine.</CAPTION>
+      <LABEL NAME="fig:gcd-machine-spec"/>
+    </FIGURE>
+  </TEXT>
 
-      <TEXT>
-  Figure<SPACE/><REF NAME="fig:gcd-machine-spec"/> shows the GCD machine described in
-  this way.  This example only hints at the generality of these
-  descriptions, since the GCD machine is a very simple case: Each
-  register has only one button, and each button and test is used only
-  once in the controller.
-      </TEXT>
+  <TEXT>
+    Figure<SPACE/><REF NAME="fig:gcd-machine-spec"/> shows the GCD machine
+    described in this way.  This example only hints at the generality of these
+    descriptions, since the GCD machine is a very simple case: Each register has
+    only one button, and each button and test is used only once in the
+    controller.
+  </TEXT>
 
-      <TEXT>
-  Unfortunately, it is difficult to read such a description.  In order
-  to understand the controller instructions we must constantly refer
-  back to the definitions of the button names and the operation names,
-  and to understand what the buttons do we may have to refer to the
-  definitions of the operation names.  We will thus transform our
-  notation to combine the information from the data-path and controller
-  descriptions so that we see it all together.
-      </TEXT>
+  <TEXT>
+    Unfortunately, it is difficult to read such a description.  In order
+    to understand the controller instructions we must constantly refer
+    back to the definitions of the button names and the operation names,
+    and to understand what the buttons do we may have to refer to the
+    definitions of the operation names.  We will thus transform our
+    notation to combine the information from the data-path and controller
+    descriptions so that we see it all together.
+  </TEXT>
 
-      <TEXT>
-  To obtain this form of description, we will replace the arbitrary
-  button and operation names by the definitions of their behavior.  That
-  is, instead of saying (in the controller) <QUOTE>Push button <SCHEMEINLINE>t&lt;-r</SCHEMEINLINE></QUOTE>
-  and separately saying (in the data paths) <QUOTE>Button <SCHEMEINLINE>t&lt;-r</SCHEMEINLINE> assigns
-    the value of the <SCHEMEINLINE>rem</SCHEMEINLINE> operation to register <SCHEMEINLINE>t</SCHEMEINLINE></QUOTE> and <QUOTE>The
-    <SCHEMEINLINE>rem</SCHEMEINLINE> operation<APOS/>s inputs are the contents of registers
-    <INDEX>register-machine language<SUBINDEX>assign@<SCHEMEINLINE>assign</SCHEMEINLINE></SUBINDEX></INDEX>
+  <TEXT>
+    To obtain this form of description, we will replace the arbitrary
+    button and operation names by the definitions of their behavior.  That
+    is, instead of saying (in the controller) <QUOTE>Push button
+    <SCHEMEINLINE>t&lt;-r</SCHEMEINLINE></QUOTE> and separately saying (in the
+    data paths) <QUOTE>Button <SCHEMEINLINE>t&lt;-r</SCHEMEINLINE> assigns the
+    value of the <SCHEMEINLINE>rem</SCHEMEINLINE> operation to register
+    <SCHEMEINLINE>t</SCHEMEINLINE></QUOTE> and <QUOTE>The
+    <SCHEMEINLINE>rem</SCHEMEINLINE> operation<APOS/>s inputs are the contents
+    of registers
+    <INDEX>register-machine language
+    <SUBINDEX>assign@<SCHEMEINLINE>assign</SCHEMEINLINE></SUBINDEX></INDEX>
     <!-- \indcodeplus{assign}{(in register machine)}-->
-    <INDEX>register-machine language<SUBINDEX>op@<SCHEMEINLINE>op</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>op@<SCHEMEINLINE>op</SCHEMEINLINE></SUBINDEX></INDEX>
     <!-- \indcodeplus{op}{(in register machine)}-->
-    <INDEX>register-machine language<SUBINDEX>reg@<SCHEMEINLINE>reg</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>reg@<SCHEMEINLINE>reg</SCHEMEINLINE></SUBINDEX></INDEX>
     <!-- \indcodeplus{reg}{(in register machine)}-->
-    <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE>,</QUOTE> we will say (in the controller) <QUOTE>Push the
-    button that assigns to register <SCHEMEINLINE>t</SCHEMEINLINE> the value of the <SCHEMEINLINE>rem</SCHEMEINLINE>
-    operation on the contents of registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE>.</QUOTE>
-  Similarly, instead of saying (in the controller) <QUOTE>Perform the <SCHEMEINLINE>=</SCHEMEINLINE> test</QUOTE> and separately saying (in the data paths) <QUOTE>The <SCHEMEINLINE>=</SCHEMEINLINE> test operates on the contents of register <SCHEMEINLINE>b</SCHEMEINLINE> and the
-    constant 0,</QUOTE> we will say <QUOTE>Perform the <SCHEMEINLINE>=</SCHEMEINLINE> test on the
-    <INDEX>register-machine language<SUBINDEX>const@<SCHEMEINLINE>const</SCHEMEINLINE></SUBINDEX></INDEX>
+    <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE>,</QUOTE>
+    we will say (in the controller) <QUOTE>Push the button that assigns to
+    register <SCHEMEINLINE>t</SCHEMEINLINE> the value of the
+    <SCHEMEINLINE>rem</SCHEMEINLINE> operation on the contents of registers
+    <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE>.</QUOTE>
+    Similarly, instead of saying (in the controller) <QUOTE>Perform the
+    <SCHEMEINLINE>=</SCHEMEINLINE> test</QUOTE> and separately saying (in the
+    data paths) <QUOTE>The <SCHEMEINLINE>=</SCHEMEINLINE> test operates on the
+    contents of register <SCHEMEINLINE>b</SCHEMEINLINE> and the
+    constant 0,</QUOTE> we will say <QUOTE>Perform the
+    <SCHEMEINLINE>=</SCHEMEINLINE> test on the
+    <INDEX>register-machine language
+    <SUBINDEX>const@<SCHEMEINLINE>const</SCHEMEINLINE></SUBINDEX></INDEX>
     <!-- \indcodeplus{const}{(in register machine)}-->
-    contents of register <SCHEMEINLINE>b</SCHEMEINLINE> and the constant 0.</QUOTE>  We will omit the
-  data-path description, leaving only the controller sequence.  Thus,
-  the GCD machine is described as follows:
-
-  <SNIPPET EVAL="no">
-    <!-- 
-        %(registers a b t)
-        %(operations rem =)
+    contents of register <SCHEMEINLINE>b</SCHEMEINLINE> and the
+    constant 0.</QUOTE>  We will omit the data-path description, leaving only
+    the controller sequence.  Thus, the GCD machine is described as follows:
+    <SNIPPET EVAL="no">
+      <!-- 
+           %(registers a b t)
+           %(operations rem =)
       -->
-    <SCHEME>
+      <SCHEME>
       (controller
       test-b
       (test (op =) (reg b) (const 0))
@@ -190,8 +218,8 @@ controller(
       (assign b (reg t))
       (goto (label test-b))
       gcd-done)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 controller(
      "test-b",
      list(test(list(op("="), reg(b), constant(0))),
@@ -201,16 +229,15 @@ controller(
           assign("b", reg(t)),
           go_to(label("test-b"))),
      "gcd-done");
-    </JAVASCRIPT>
+      </JAVASCRIPT>
     </SNIPPET>
-      </TEXT>
+  </TEXT>
 
-      <TEXT>
-  This form of description is easier to read than the kind illustrated
-  in Figure<SPACE/><REF NAME="fig:gcd-machine-spec"/>, but it also has disadvantages:
-  <UL>
-    
-    <LI>It is more verbose for large machines,
+  <TEXT>
+    This form of description is easier to read than the kind illustrated
+    in Figure<SPACE/><REF NAME="fig:gcd-machine-spec"/>, but it also has disadvantages:
+    <UL>
+      <LI>It is more verbose for large machines,
       because complete descriptions of the data-path elements are repeated
       whenever the elements are mentioned in the controller instruction
       sequence.  (This is not a problem in the GCD example, because each
@@ -218,111 +245,162 @@ controller(
       data-path descriptions obscures the actual data-path structure of the
       machine; it is not obvious for a large machine how many registers,
       operations, and buttons there are and how they are interconnected.
+      </LI>
+      <LI>
+	Because the controller instructions in a machine definition look like
+	<SPLITINLINE>
+	  <SCHEME>Lisp</SCHEME>
+	  <JAVASCRIPT>JavaScript</JAVASCRIPT>
+	</SPLITINLINE>
+	expressions, it is easy to forget that they are
+	not arbitrary
+	<SPLITINLINE>
+	  <SCHEME>Lisp.</SCHEME>
+	  <JAVASCRIPT>JavaScript.</JAVASCRIPT>
+	</SPLITINLINE>
+	expressions.  They can notate only legal machine operations.  For
+	example, operations can operate directly only on constants and the
+	contents of registers, not on the results of other operations.
+      </LI>
+    </UL>
+  </TEXT>
 
-    </LI>
-    <LI>Because the controller instructions in a machine definition
-      look like <SPLITINLINE><SCHEME>Lisp</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE> expressions, it is easy to forget that they are
-      not arbitrary <SPLITINLINE><SCHEME>Lisp</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE> expressions.  They can notate only legal machine
-      operations.  For example, operations can operate directly only on
-      constants and the contents of registers, not on the results of other
-      operations.
-    </LI>
-
-  </UL>
-      </TEXT>
+  <TEXT>
+    In spite of these disadvantages, we will use this register-machine
+    language throughout this chapter, because we will be more concerned with
+    understanding controllers than with understanding the elements and
+    connections in data paths.  We should keep in mind,
+    however, that data-path design is crucial in designing real machines.
+  </TEXT>
 
-      <TEXT>
-  In spite of these disadvantages, we will use this register-machine
-  language throughout this chapter, because we will be more concerned with
-  understanding controllers than with understanding the elements and
-  connections in data paths.  We should keep in mind,
-  however, that data-path design is crucial in designing real machines.
-      </TEXT>
+  <EXERCISE>
+    <!--  \indcode{factorial}[register machine for (iterative)] -->
+    Use the register-machine language to describe the iterative factorial
+    machine of exercise<SPACE/><REF NAME="ex:iterative-fact"/>.
+    <LABEL NAME="ex:iterative-fact-2"/>
+  </EXERCISE>
 
-      <EXERCISE>
-  <!--  \indcode{factorial}[register machine for (iterative)] -->
-  Use the register-machine language to describe
-  the iterative factorial machine of exercise<SPACE/><REF NAME="ex:iterative-fact"/>.
-  <LABEL NAME="ex:iterative-fact-2"/>
-      </EXERCISE>
 
+  <SUBHEADING>
+    <NAME>Actions</NAME>
+  </SUBHEADING>
 
-      <SUBHEADING>
-  <NAME>Actions</NAME>
-      </SUBHEADING>
+  <INDEX>actions, in register machine|(</INDEX>
+  <INDEX>register machine<SUBINDEX>actions|(</SUBINDEX></INDEX>
 
-      <INDEX>actions, in register machine|(</INDEX>
-      <INDEX>register machine<SUBINDEX>actions|(</SUBINDEX></INDEX>
-
-      <TEXT>
-  Let us modify the GCD machine so that we can type in the numbers
-  whose GCD we want and get the answer printed at our terminal.  We will
-  not discuss how to make a machine that can read and print, but will
-  assume (as we do when we use <SPLITINLINE><SCHEME><SCHEMEINLINE>read</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>prompt</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and <SCHEMEINLINE>display</SCHEMEINLINE> in
-  <SPLITINLINE><SCHEME>Scheme</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE>) that
-  they are available as primitive operations.<SPLITINLINE><SCHEME><FOOTNOTE>This assumption
-    glosses over a great deal of complexity.  Usually a large portion of
-    the implementation of a <SPLITINLINE><SCHEME>Lisp</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE> system is dedicated to making reading
+  <TEXT>
+    Let us modify the GCD machine so that we can type in the numbers
+    whose GCD we want and get the answer printed at our terminal.  We will
+    not discuss how to make a machine that can read and print, but will
+    assume (as we do when we use
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>read</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>prompt</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    and <SCHEMEINLINE>display</SCHEMEINLINE> in
+    <SPLITINLINE>
+      <SCHEME>Scheme)</SCHEME>
+      <JAVASCRIPT>JavaScript)</JAVASCRIPT>
+    </SPLITINLINE>
+    that they are available as primitive
+    operations.<SPLITINLINE><SCHEME><FOOTNOTE>This assumption glosses over a
+    great deal of complexity.  Usually a large portion of the implementation of
+    a Lisp 
+    <SPLITINLINE>
+      <SCHEME>system</SCHEME>
+      <JAVASCRIPT>system, for example,</JAVASCRIPT>
+    </SPLITINLINE>
+    is dedicated to making reading
     and printing work.</FOOTNOTE></SCHEME></SPLITINLINE>
-      </TEXT>
+  </TEXT>
 
-      <TEXT>
-  <!-- \indcodeplus{read}{operation in register machine}-->
-  <SPLITINLINE><SCHEME><SCHEMEINLINE>Read</SCHEMEINLINE></SCHEME><JAVASCRIPT>The operation <JAVASCRIPTINLINE>read</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is like the operations we have been using in that it
-  produces a value that can be stored in a register.  But <SCHEMEINLINE>read</SCHEMEINLINE>
-  does not take inputs from any registers; its value depends on
-  something that happens outside the parts of the machine we are
-  designing.  We will allow our machine<APOS/>s operations to have such
-  behavior, and thus will draw and notate the use of <SCHEMEINLINE>read</SCHEMEINLINE> just as
-  we do any other operation that computes a value.
-      </TEXT>
+  <TEXT>
+    <!-- \indcodeplus{read}{operation in register machine}-->
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Read</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>The operation <JAVASCRIPTINLINE>prompt</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is like the operations we have been using in that it produces a value that
+    can be stored in a register.  But
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>read</SCHEMEINLINE>
+      </SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>prompt</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    does not take inputs from any registers; its value depends on
+    something that happens outside the parts of the machine we are
+    designing.  We will allow our machine<APOS/>s operations to have such
+    behavior, and thus will draw and notate the use of
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>read</SCHEMEINLINE>
+      </SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>prompt</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    just as we do any other operation that computes a value.
+  </TEXT>
 
-      <TEXT>
-  <!-- \indcodeplus{print}{operation in register machine}-->
-  <SPLITINLINE><SCHEME><SCHEMEINLINE>Print</SCHEMEINLINE></SCHEME><JAVASCRIPT>The operation <JAVASCRIPTINLINE>print</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, on the other hand, differs from the operations we have
-  been using in a fundamental way: It does not produce an output value
-  to be stored in a register.  Though it has an effect, this effect is
-  not on a part of the machine we are designing.  We will refer to this
-  kind of operation as an <EM>action</EM>.  We will represent an action in
-  a data-path diagram just as we represent an operation that computes a
-  value<EMDASH/>as a trapezoid that contains the name of the action.
-  Arrows point to the action box from any inputs (registers or
-  constants).  We also associate a button with the action.  Pushing the
-  button makes the action happen.  To make a controller push an action
-  <INDEX>register-machine language<SUBINDEX>perform@<SCHEMEINLINE>perform</SCHEMEINLINE></SUBINDEX></INDEX>
-  <!-- \indcodeplus{perform}{(in register machine)}-->
-  button we use a new kind of instruction called <SCHEMEINLINE>perform</SCHEMEINLINE>.  Thus,
-  the action of printing the contents of register <SCHEMEINLINE>a</SCHEMEINLINE> is represented
-  in a controller sequence by the instruction
-  <SNIPPET EVAL="no">
-    <SCHEME>
+  <TEXT>
+    <!-- \indcodeplus{print}{operation in register machine}-->
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Print</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT>The operation <JAVASCRIPTINLINE>display</JAVASCRIPTINLINE>,
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    on the other hand, differs from the operations we have
+    been using in a fundamental way: It does not produce an output value
+    to be stored in a register.  Though it has an effect, this effect is
+    not on a part of the machine we are designing.  We will refer to this
+    kind of operation as an <EM>action</EM>.  We will represent an action in
+    a data-path diagram just as we represent an operation that computes a
+    value<EMDASH/>as a trapezoid that contains the name of the action.
+    Arrows point to the action box from any inputs (registers or
+    constants).  We also associate a button with the action.  Pushing the
+    button makes the action happen.  To make a controller push an action
+    <INDEX>register-machine language
+    <SUBINDEX>perform@<SCHEMEINLINE>perform</SCHEMEINLINE></SUBINDEX></INDEX>
+    <!-- \indcodeplus{perform}{(in register machine)}-->
+    button we use a new kind of instruction called
+    <SCHEMEINLINE>perform</SCHEMEINLINE>.  Thus,
+    the action of printing the contents of register
+    <SCHEMEINLINE>a</SCHEMEINLINE> is represented
+    in a controller sequence by the instruction
+    <SNIPPET EVAL="no">
+      <SCHEME>
       (perform (op print) (reg a))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 perform(list(op("print"), reg("a")))      
-    </JAVASCRIPT>
-  </SNIPPET>
-    
-      </TEXT>
-
-      <TEXT>
-  Figure<SPACE/><REF NAME="fig:gcd-with-io"/> shows the data paths and controller for
-  the new GCD machine.  Instead of having the machine stop after
-  printing the answer, we have made it start over, so that it repeatedly
-  reads a pair of numbers, computes their GCD, and prints the result.
-  This structure is like the driver loops we used in the interpreters of
-  chapter<SPACE/>4.
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-  <SPLIT>
-    <SCHEME>
-<FIGURE>
-  <FIGURE src="img_original/Fig5.4c.std.svg"/>
-  <SNIPPET EVAL="no">
-    <!-- 
-        % (registers a b t)
-        % (operations read = rem print)
-      -->
+  <TEXT>
+    <SPLITINLINE>
+      <SCHEME>
+	Figure<SPACE/><REF NAME="fig:gcd-with-io_scheme"/>
+      </SCHEME>
+      <JAVASCRIPT>
+	Figure<SPACE/><REF NAME="fig:gcd-with-io"/>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    shows the data paths and controller for
+    the new GCD machine.  Instead of having the machine stop after
+    printing the answer, we have made it start over, so that it repeatedly
+    reads a pair of numbers, computes their GCD, and prints the result.
+    This structure is like the driver loops we used in the interpreters of
+    chapter<SPACE/>4.
+    <!--  % (registers a b t) (operations read = rem print) -->
+    <SPLIT>
       <SCHEME>
+	<FIGURE>
+	  <FIGURE src="img_original/Fig5.4c.std.svg"/>
+	  <SNIPPET EVAL="no">
+	    <SCHEME>
         (controller
         gcd-loop
         (assign a (op read))
@@ -337,17 +415,17 @@ perform(list(op("print"), reg("a")))
         gcd-done
         (perform (op print) (reg a))
         (goto (label gcd-loop)))
+	    </SCHEME>
+	  </SNIPPET>
+	  <CAPTION>A GCD machine that reads inputs and prints results.</CAPTION>
+	  <LABEL NAME="fig:gcd-with-io_scheme"/>
+	</FIGURE>
       </SCHEME>
-      </SNIPPET>
-      <CAPTION>A GCD machine that reads inputs and prints results.</CAPTION>
-      <LABEL NAME="fig:gcd-with-io"/>
-    </FIGURE>
-  </SCHEME>
-  <JAVASCRIPT>
-    <FIGURE>
-      <FIGURE src="img_javascript/Fig5.4c.std.svg"/>      
-      <SNIPPET EVAL="no">
-        <JAVASCRIPT>
+      <JAVASCRIPT>
+	<FIGURE>
+	  <FIGURE src="img_javascript/Fig5.4c.std.svg"/>      
+	  <SNIPPET EVAL="no">
+            <JAVASCRIPT>
 controller(
     list(      
        "gcd-loop",
@@ -363,17 +441,15 @@ controller(
        "gcd-done",
        perform(list(op("print"), reg("a"))),
        go_to(label("gcd-loop"))));
-        </JAVASCRIPT>
-      </SNIPPET>
-      <CAPTION>A GCD machine that reads inputs and prints results.</CAPTION>
-      <LABEL NAME="fig:gcd-with-io"/>
-    </FIGURE>
-  </JAVASCRIPT>
-</SPLIT>
-
-<INDEX>register machine<SUBINDEX>language for describing|)</SUBINDEX></INDEX>
-  <INDEX>actions, in register machine|)</INDEX>
-  <INDEX>register machine<SUBINDEX>actions|)</SUBINDEX></INDEX>
-      </TEXT>
-
-    </SUBSECTION>
+            </JAVASCRIPT>
+	  </SNIPPET>
+	  <CAPTION>A GCD machine that reads inputs and prints results.</CAPTION>
+	  <LABEL NAME="fig:gcd-with-io"/>
+	</FIGURE>
+      </JAVASCRIPT>
+    </SPLIT>
+    <INDEX>register machine<SUBINDEX>language for describing|)</SUBINDEX></INDEX>
+    <INDEX>actions, in register machine|)</INDEX>
+    <INDEX>register machine<SUBINDEX>actions|)</SUBINDEX></INDEX>
+  </TEXT>
+</SUBSECTION>
diff --git a/xml/chapter5/section1/subsection2.xml b/xml/chapter5/section1/subsection2.xml
index f03b3fd97..ab819a715 100644
--- a/xml/chapter5/section1/subsection2.xml
+++ b/xml/chapter5/section1/subsection2.xml
@@ -1,82 +1,93 @@
-    <SUBSECTION>
-      <NAME>
-  Abstraction in Machine Design
-      </NAME>
+<SUBSECTION>
+  <NAME>
+    Abstraction in Machine Design
+  </NAME>
 
-      <INDEX>abstraction<SUBINDEX>register@in register-machine design|(</SUBINDEX></INDEX>
+  <INDEX>abstraction
+  <SUBINDEX>register@in register-machine design|(</SUBINDEX></INDEX>
 
-      <TEXT>
-  We will often define a machine to include <QUOTE>primitive</QUOTE> operations that are
-  actually very complex.  For example, in sections<SPACE/><REF NAME="sec:eceval"/> and
-  <REF NAME="sec:compilation"/> we will treat <SPLITINLINE><SCHEME>Scheme</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE><APOS/>s environment
-  manipulations as primitive.  Such abstraction is valuable because it
-  allows us to ignore the details of parts of a machine so that we can
-  concentrate on other aspects of the design.  The fact that we have
-  swept a lot of complexity under the rug, however, does not mean that a
-  machine design is unrealistic.  We can always replace the complex
-  <QUOTE>primitives</QUOTE> by simpler primitive operations.
-      </TEXT>
+  <TEXT>
+    We will often define a machine to include <QUOTE>primitive</QUOTE>
+    operations that are actually very complex.  For example, in
+    sections<SPACE/><REF NAME="sec:eceval"/> and <REF NAME="sec:compilation"/>
+    we will treat
+    <SPLITINLINE>
+      <SCHEME>Scheme<APOS/></SCHEME>
+      <JAVASCRIPT>JavaScript<APOS/>s</JAVASCRIPT>
+    </SPLITINLINE>
+    environment manipulations as primitive.  Such abstraction is valuable
+    because it allows us to ignore the details of parts of a machine so that we
+    can concentrate on other aspects of the design.  The fact that we have
+    swept a lot of complexity under the rug, however, does not mean that a
+    machine design is unrealistic.  We can always replace the complex
+    <QUOTE>primitives</QUOTE> by simpler primitive operations.
+  </TEXT>
 
-      <TEXT>
-  Consider the GCD machine. The machine has an instruction that computes
-  the remainder of the contents of registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE> and
-  assigns the result to register <SCHEMEINLINE>t</SCHEMEINLINE>.  If we want to construct the
-  GCD machine without using a primitive remainder operation,
-  we must specify how to compute remainders in terms of simpler
-  operations, such as subtraction.  Indeed, we can write a 
-  <SPLITINLINE><SCHEME>Scheme procedure</SCHEME><JAVASCRIPT>JavaScript function</JAVASCRIPT></SPLITINLINE>
-  that finds remainders in this way:
-
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    Consider the GCD machine. The machine has an instruction that computes
+    the remainder of the contents of registers <SCHEMEINLINE>a</SCHEMEINLINE>
+    and <SCHEMEINLINE>b</SCHEMEINLINE> and assigns the result to register
+    <SCHEMEINLINE>t</SCHEMEINLINE>.  If we want to construct the GCD machine
+    without using a primitive remainder operation, we must specify how to
+    compute remainders in terms of simpler operations, such as subtraction.
+    Indeed, we can write a 
+    <SPLITINLINE>
+      <SCHEME>Scheme procedure</SCHEME>
+      <JAVASCRIPT>JavaScript function</JAVASCRIPT>
+    </SPLITINLINE>
+    that finds remainders in this way:
+    <SNIPPET>
+      <NAME>remainder_example</NAME>
+      <JAVASCRIPT>
+remainder(29, 5);
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>remainder</NAME>
+      <EXAMPLE>remainder_example</EXAMPLE>
+      <SCHEME>
       (define (remainder n d)
       (if (&lt; n d)
       n
       (remainder (- n d) d)))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function remainder(n, d) {
     return n &lt; d
         ? n
         : remainder(n - d, d);
 }
-    </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  We can thus replace the remainder operation in the GCD machine<APOS/>s
-  data paths with a subtraction operation and a comparison test.
-  Figure<SPACE/><REF NAME="fig:gcd-machine-rem"/> shows the data paths and controller
-  for the elaborated machine.
-  The instruction
-
-  <FIGURE>
-    <FIGURE src="img_original/Fig5.5b.std.svg"/>
-    <LABEL NAME="fig:gcd-machine-rem"/>
-    <CAPTION>Data paths and controller for the elaborated GCD  machine.</CAPTION>
-  </FIGURE>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-  <SNIPPET EVAL="no">
-    <SCHEME>
+  <TEXT>
+    We can thus replace the remainder operation in the GCD machine<APOS/>s
+    data paths with a subtraction operation and a comparison test.
+    Figure<SPACE/><REF NAME="fig:gcd-machine-rem"/> shows the data paths and
+    controller for the elaborated machine. The instruction
+    <FIGURE>
+      <FIGURE scale_factor="4" src="img_original/Fig5.5b.std.svg"/>
+      <LABEL NAME="fig:gcd-machine-rem"/>
+      <CAPTION>
+	Data paths and controller for the elaborated GCD  machine.
+      </CAPTION>
+    </FIGURE>
+    <SNIPPET EVAL="no">
+      <SCHEME>
       (assign t (op rem) (reg a) (reg b))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 assign("t", list(op("rem"), reg("a"), reg("b")))
-    </JAVASCRIPT>
-  </SNIPPET>
-
-  in the GCD controller definition is replaced by a sequence of
-  instructions that contains a loop, as shown in
-  figure<SPACE/><REF NAME="fig:gcd-machine-rem-controller"/>.
-
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <!-- 
-        %(registers a b t)
-        %(operations &lt; - =)
-      -->
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    in the GCD controller definition is replaced by a sequence of
+    instructions that contains a loop, as shown in
+    figure<SPACE/><REF NAME="fig:gcd-machine-rem-controller"/>.
+    <!--  %(registers a b t) %(operations &lt; - =) -->
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       (controller
       test-b
       (test (op =) (reg b) (const 0))
@@ -92,8 +103,8 @@ assign("t", list(op("rem"), reg("a"), reg("b")))
       (assign b (reg t))
       (goto (label test-b))
       gcd-done)
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 controller(
     "test-b",
     list(test(list(op("="), reg("b"), constant(0))),
@@ -109,21 +120,20 @@ controller(
          assign("b", reg("t")),
          go_to(label("test-b"))),
     "gcd-done");
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>Controller instruction sequence for the GCD machine in
-  figure<SPACE/><REF NAME="fig:gcd-machine-rem"/>.</CAPTION>
-  <LABEL NAME="fig:gcd-machine-rem-controller"/>
-        </FIGURE>
-      </TEXT>
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>Controller instruction sequence for the GCD machine in
+      figure<SPACE/><REF NAME="fig:gcd-machine-rem"/>.</CAPTION>
+      <LABEL NAME="fig:gcd-machine-rem-controller"/>
+    </FIGURE>
+  </TEXT>
 
-      <EXERCISE>
-  <!--  \indcode{sqrt}[register machine for] -->
-  Design a machine to compute square roots using Newton<APOS/>s method, as
-  described in section<SPACE/><REF NAME="sec:sqrt"/>:
-
-  <SNIPPET>
-    <SCHEME>
+  <EXERCISE>
+    <!--  \indcode{sqrt}[register machine for] -->
+    Design a machine to compute square roots using Newton<APOS/>s method, as
+    described in section<SPACE/><REF NAME="sec:sqrt"/>:
+    <SNIPPET>
+      <SCHEME>
       (define (sqrt x)
       (define (good-enough? guess)
       (&lt; (abs (- (square guess) x)) 0.001))
@@ -134,32 +144,65 @@ controller(
             guess
             (sqrt-iter (improve guess))))
       (sqrt-iter 1.0))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT_RUN>
+function square(x) {
+    return x * x;
+}
+
+function average(x,y) {
+    return (x + y) / 2;
+}
+
 function sqrt(x) {
-    function good_enough(guess, x) {
-        return abs(square(guess) - x) &lt; 0.001;
+    function good_enough(guess) {
+        return math_abs(square(guess) - x) &lt; 0.001;
     }
-    function improve(guess, x) {
+    function improve(guess) {
         return average(guess, x / guess);
     }
-    function sqrt_iter(guess, x) {
-        return good_enough(guess, x)
+    function sqrt_iter(guess) {
+        return good_enough(guess)
             ? guess
-            : sqrt_iter(improve(guess, x), x);
+            : sqrt_iter(improve(guess));
     }
     return  sqrt_iter(1.0);
 }
-    </JAVASCRIPT>
-  </SNIPPET>
 
-  Begin by assuming that <SPLITINLINE><SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and <SCHEMEINLINE>improve</SCHEMEINLINE> operations
-  are available as primitives.  Then show how to expand these in terms
-  of arithmetic operations.  Describe each version of the <SCHEMEINLINE>sqrt</SCHEMEINLINE>
-  machine design by drawing a data-path diagram and writing a controller
-  definition in the register-machine language.
-  <LABEL NAME="ex:sqrt-machine"/>
-      </EXERCISE>
-      <INDEX>abstraction<SUBINDEX>register@in register-machine design|)</SUBINDEX></INDEX>
-
-    </SUBSECTION>
+display(sqrt(4));   // Should display close to 2
+display(sqrt(9));   // Should display close to 3
+display(sqrt(100)); // Should display close to 10
+// Change 0.001 above to tune precision
+      </JAVASCRIPT_RUN>
+      <JAVASCRIPT>
+function sqrt(x) {
+    function good_enough(guess) {
+        return math_abs(square(guess) - x) &lt; 0.001;
+    }
+    function improve(guess) {
+        return average(guess, x / guess);
+    }
+    function sqrt_iter(guess) {
+        return good_enough(guess)
+            ? guess
+            : sqrt_iter(improve(guess));
+    }
+    return  sqrt_iter(1.0);
+}
+      </JAVASCRIPT>
+    </SNIPPET>
+    Begin by assuming that
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>good-enough?</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>good_enough</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    and <SCHEMEINLINE>improve</SCHEMEINLINE> operations are available as
+    primitives.  Then show how to expand these in terms of arithmetic
+    operations.  Describe each version of the <SCHEMEINLINE>sqrt</SCHEMEINLINE>
+    machine design by drawing a data-path diagram and writing a controller
+    definition in the register-machine language.
+    <LABEL NAME="ex:sqrt-machine"/>
+  </EXERCISE>
+  <INDEX>abstraction
+  <SUBINDEX>register@in register-machine design|)</SUBINDEX></INDEX>
+</SUBSECTION>
diff --git a/xml/chapter5/section1/subsection3.xml b/xml/chapter5/section1/subsection3.xml
index ed3989db3..6e0ab05e9 100644
--- a/xml/chapter5/section1/subsection3.xml
+++ b/xml/chapter5/section1/subsection3.xml
@@ -1,29 +1,31 @@
-    <SUBSECTION>
-      <NAME>
-  Subroutines
-      </NAME>
+<SUBSECTION>
+  <NAME>
+    Subroutines
+  </NAME>
 
-      <LABEL NAME="sec:subroutines"/>
-      <INDEX>register machine<SUBINDEX>subroutine|(</SUBINDEX></INDEX>
-      <INDEX>subroutine in register machine|(</INDEX>
+  <LABEL NAME="sec:subroutines"/>
+  <INDEX>register machine<SUBINDEX>subroutine|(</SUBINDEX></INDEX>
+  <INDEX>subroutine in register machine|(</INDEX>
 
-      <TEXT>
-  When designing a machine to perform a computation, we would often
-  prefer to arrange for components to be shared by different parts of
-  the computation rather than duplicate the components.  Consider a
-  machine that includes two GCD computations<EMDASH/>one that finds the GCD of
-  the contents of registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE> and one that finds the
-  GCD of the contents of registers <SCHEMEINLINE>c</SCHEMEINLINE> and <SCHEMEINLINE>d</SCHEMEINLINE>.  We might start
-  by assuming we have a primitive <SCHEMEINLINE>gcd</SCHEMEINLINE> operation, then expand the
-  two instances of <SCHEMEINLINE>gcd</SCHEMEINLINE> in terms of more primitive operations.
-  Figure<SPACE/><REF NAME="fig:gcd-machine-1"/> shows just the GCD portions of the
-  resulting machine<APOS/>s data paths, without showing how they connect to
-  the rest of the machine.  The figure also shows the corresponding
-  portions of the machine<APOS/>s controller sequence.
-
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <SCHEME>
+  <TEXT>
+    When designing a machine to perform a computation, we would often
+    prefer to arrange for components to be shared by different parts of
+    the computation rather than duplicate the components.  Consider a
+    machine that includes two GCD computations<EMDASH/>one that finds the GCD of
+    the contents of registers <SCHEMEINLINE>a</SCHEMEINLINE> and
+    <SCHEMEINLINE>b</SCHEMEINLINE> and one that finds the
+    GCD of the contents of registers <SCHEMEINLINE>c</SCHEMEINLINE> and
+    <SCHEMEINLINE>d</SCHEMEINLINE>.  We might start
+    by assuming we have a primitive <SCHEMEINLINE>gcd</SCHEMEINLINE> operation,
+    then expand the two instances of <SCHEMEINLINE>gcd</SCHEMEINLINE> in terms
+    of more primitive operations. Figure<SPACE/><REF NAME="fig:gcd-machine-1"/>
+    shows just the GCD portions of the resulting machine<APOS/>s data paths,
+    without showing how they connect to the rest of the machine.  The figure
+    also shows the corresponding portions of the machine<APOS/>s controller
+    sequence.
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       gcd-1
       (test (op =) (reg b) (const 0))
       (branch (label after-gcd-1))
@@ -41,8 +43,8 @@
       (assign d (reg s))
       (goto (label gcd-2))
       after-gcd-2
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 list(...,      
      "gcd-1",
      test(list(op("="), reg("b"), constant(0))),
@@ -62,52 +64,54 @@ list(...,
      go_to(label("gcd-2")),
      "after-gcd-2",
      ...
-    </JAVASCRIPT>
-  </SNIPPET>
-
-  <CAPTION>Portions of the data paths and controller sequence for
-  a machine with two GCD computations.</CAPTION>
-  <LABEL NAME="fig:gcd-machine-1"/>
-  </FIGURE>
-      </TEXT>
-
-      <TEXT>
-  This machine has two remainder operation boxes and two boxes for
-  testing equality.  If the duplicated components are complicated, as is the
-  remainder box, this will not be an economical way to build the
-  machine.  We can avoid duplicating the data-path components by using
-  the same components for both GCD computations, provided that doing so
-  will not affect the rest of the larger machine<APOS/>s computation.  If the
-  values in registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE> are not needed by the time the
-  controller gets to <SCHEMEINLINE>gcd-2</SCHEMEINLINE> (or if these values can be moved to
-  other registers for safekeeping), we can change the machine so that
-  it uses registers <SCHEMEINLINE>a</SCHEMEINLINE> and <SCHEMEINLINE>b</SCHEMEINLINE>, rather than registers <SCHEMEINLINE>c</SCHEMEINLINE>
-  and <SCHEMEINLINE>d</SCHEMEINLINE>, in computing the second GCD as well as the first.  If we
-  do this, we obtain the controller sequence shown in
-  figure<SPACE/><REF NAME="fig:gcd-machine-2"/>.
-      </TEXT>
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>Portions of the data paths and controller sequence for
+      a machine with two GCD computations.</CAPTION>
+      <LABEL NAME="fig:gcd-machine-1"/>
+    </FIGURE>
+  </TEXT>
 
-      <TEXT>
-  We have removed the duplicate data-path components
-  (so that the data paths are again as in figure<SPACE/><REF NAME="fig:gcd-machine"/>),
-  but the controller
-  now has two GCD sequences that differ only in their entry-point
-  labels.  It would be better to replace these two sequences by branches
-  to a single sequence<EMDASH/>a <SCHEMEINLINE>gcd</SCHEMEINLINE> <EM>subroutine</EM><EMDASH/>at the end of
-  which we branch back to the correct place in the main instruction
-  sequence.  We can accomplish this as follows: Before branching to <SCHEMEINLINE>gcd</SCHEMEINLINE>, we place a distinguishing value (such as 0 or<SPACE/>1) into a special
-  register, 
-  <!-- \indcodeplus{continue}{register}-->
-  <SCHEMEINLINE>continue</SCHEMEINLINE>.  At the end of the <SCHEMEINLINE>gcd</SCHEMEINLINE> subroutine we
-  return either to <SCHEMEINLINE>after-gcd-1</SCHEMEINLINE> or to <SCHEMEINLINE>after-gcd-2</SCHEMEINLINE>, depending
-  on the value of the <SCHEMEINLINE>continue</SCHEMEINLINE> register.
-  Figure<SPACE/><REF NAME="fig:gcd-machine-2cont"/> shows the relevant portion of the
-  resulting controller sequence, which includes only a single copy of the
-  <SCHEMEINLINE>gcd</SCHEMEINLINE> instructions.
+  <TEXT>
+    This machine has two remainder operation boxes and two boxes for
+    testing equality.  If the duplicated components are complicated, as is the
+    remainder box, this will not be an economical way to build the
+    machine.  We can avoid duplicating the data-path components by using
+    the same components for both GCD computations, provided that doing so
+    will not affect the rest of the larger machine<APOS/>s computation.  If the
+    values in registers <SCHEMEINLINE>a</SCHEMEINLINE> and
+    <SCHEMEINLINE>b</SCHEMEINLINE> are not needed by the time the
+    controller gets to <SCHEMEINLINE>gcd-2</SCHEMEINLINE> (or if these values
+    can be moved to other registers for safekeeping), we can change the machine
+    so that it uses registers <SCHEMEINLINE>a</SCHEMEINLINE> and
+    <SCHEMEINLINE>b</SCHEMEINLINE>, rather than registers
+    <SCHEMEINLINE>c</SCHEMEINLINE> and <SCHEMEINLINE>d</SCHEMEINLINE>, in
+    computing the second GCD as well as the first.  If we do this, we obtain the
+    controller sequence shown in
+    figure<SPACE/><REF NAME="fig:gcd-machine-2"/>.
+  </TEXT>
 
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <SCHEME>
+  <TEXT>
+    We have removed the duplicate data-path components (so that the data paths
+    are again as in figure<SPACE/><REF NAME="fig:gcd-machine"/>), but the
+    controller now has two GCD sequences that differ only in their entry-point
+    labels.  It would be better to replace these two sequences by branches to a
+    single sequence<EMDASH/>a <SCHEMEINLINE>gcd</SCHEMEINLINE>
+    <EM>subroutine</EM><EMDASH/>at the end of which we branch back to the
+    correct place in the main instruction sequence.  We can accomplish this as
+    follows: Before branching to <SCHEMEINLINE>gcd</SCHEMEINLINE>, we place a
+    distinguishing value (such as 0 or<SPACE/>1) into a special register, 
+    <!-- \indcodeplus{continue}{register}-->
+    <SCHEMEINLINE>continue</SCHEMEINLINE>.  At the end of the
+    <SCHEMEINLINE>gcd</SCHEMEINLINE> subroutine we return either to
+    <SCHEMEINLINE>after-gcd-1</SCHEMEINLINE> or to <SCHEMEINLINE>after-gcd-2</SCHEMEINLINE>, depending
+    on the value of the <SCHEMEINLINE>continue</SCHEMEINLINE> register.
+    Figure<SPACE/><REF NAME="fig:gcd-machine-2cont"/> shows the relevant portion
+    of the resulting controller sequence, which includes only a single copy of
+    the <SCHEMEINLINE>gcd</SCHEMEINLINE> instructions.
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       gcd-1
       (test (op =) (reg b) (const 0))
       (branch (label after-gcd-1))
@@ -125,8 +129,8 @@ list(...,
       (assign b (reg t))
       (goto (label gcd-2))
       after-gcd-2
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 list(...,
      "gcd-1",
      test(list(op("="), reg("b"), constant(0))),
@@ -146,17 +150,16 @@ list(...,
      go_to(label("gcd-2")),
      "after-gcd-2",
      ...
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>Portions of the controller sequence for a machine that
-  uses the same data-path components for two different GCD
-  computations.</CAPTION>
-  <LABEL NAME="fig:gcd-machine-2"/>
-  </FIGURE>
-
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <SCHEME>
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>Portions of the controller sequence for a machine that
+      uses the same data-path components for two different GCD
+      computations.</CAPTION>
+      <LABEL NAME="fig:gcd-machine-2"/>
+    </FIGURE>
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       gcd
       (test (op =) (reg b) (const 0))
       (branch (label gcd-done))
@@ -169,18 +172,18 @@ list(...,
       (branch (label after-gcd-1))
       (goto (label after-gcd-2))
       <LATEXINLINE>$\vdots$</LATEXINLINE>
-      <EM>;; Before branching to <SCHEMEINLINE>gcd</SCHEMEINLINE> from the first place where</EM>
+      <EM>;; Before branching to gcd from the first place where</EM>
       <EM>;; it is needed, we place <LATEXINLINE>$0$</LATEXINLINE> in the <SCHEMEINLINE>continue</SCHEMEINLINE> register</EM>
       (assign continue (const 0))
       (goto (label gcd))
       after-gcd-1
       <LATEXINLINE>$\vdots$</LATEXINLINE>
-      <EM>;; Before the second use of <SCHEMEINLINE>gcd</SCHEMEINLINE>, we place <LATEXINLINE>$1$</LATEXINLINE> in the <SCHEMEINLINE>continue</SCHEMEINLINE> register</EM>
+      <EM>;; Before the second use of gcd, we place <LATEXINLINE>$1$</LATEXINLINE> in the <SCHEMEINLINE>continue</SCHEMEINLINE> register</EM>
       (assign continue (const 1))
       (goto (label gcd))
       after-gcd-2
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 list(...,      
      "gcd",
      test(list(op("="), reg("b"), constant(0))),
@@ -206,16 +209,18 @@ list(...,
      go_to(label("gcd")),
      "after-gcd-2",
      ...)
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>Using a <SCHEMEINLINE>continue</SCHEMEINLINE> register to avoid
-  the duplicate controller sequence in figure<SPACE/><REF NAME="fig:gcd-machine-2"/>.</CAPTION>
-  <LABEL NAME="fig:gcd-machine-2cont"/>
-  </FIGURE>
-
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <SCHEME>
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>
+	Using a <SCHEMEINLINE>continue</SCHEMEINLINE> register to avoid
+	the duplicate controller sequence in
+	figure<SPACE/><REF NAME="fig:gcd-machine-2"/>.
+      </CAPTION>
+      <LABEL NAME="fig:gcd-machine-2cont"/>
+    </FIGURE>
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       gcd
       (test (op =) (reg b) (const 0))
       (branch (label gcd-done))
@@ -236,8 +241,8 @@ list(...,
       (assign continue (label after-gcd-2))
       (goto (label gcd))
       after-gcd-2
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 list(...,
      "gcd",
      test(list(op("="), reg("b"), constant(0))),
@@ -260,57 +265,74 @@ list(...,
      go_to(label("gcd")),
      "after-gcd-2",
      ...)
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>Assigning labels to the <SCHEMEINLINE>continue</SCHEMEINLINE> register simplifies
-  and generalizes the strategy shown in figure<SPACE/><REF NAME="fig:gcd-machine-2cont"/>.</CAPTION>
-  <LABEL NAME="fig:gcd-mach-2labels"/>
-  </FIGURE>
-      </TEXT>
-
-      <TEXT>
-  This is a reasonable approach for handling small problems, but it
-  would be awkward if there were many instances of GCD computations in
-  the controller sequence.  To decide where to continue executing after
-  the <SCHEMEINLINE>gcd</SCHEMEINLINE> subroutine, we would need tests in the data paths and
-  branch instructions in the controller for all the places that use <SCHEMEINLINE>gcd</SCHEMEINLINE>.
-  A more powerful method for implementing subroutines is to have
-  the <SCHEMEINLINE>continue</SCHEMEINLINE> register hold the label of the entry point in the
-  controller sequence at which execution should continue when the subroutine is finished.
-  Implementing this strategy requires a new
-  kind of connection between the data paths and the controller of a
-  register machine: There must be a way to assign to a register a label
-  in the controller sequence in such a way that this value can be fetched
-  from the register and used to continue execution at the designated
-  entry point.
-      </TEXT>
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>
+	Assigning labels to the <SCHEMEINLINE>continue</SCHEMEINLINE> register
+	simplifies  and generalizes the strategy shown in
+	figure<SPACE/><REF NAME="fig:gcd-machine-2cont"/>.
+      </CAPTION>
+      <LABEL NAME="fig:gcd-mach-2labels"/>
+    </FIGURE>
+  </TEXT>
 
-      <TEXT>
-  <!-- \indcodeplus{assign}{(in register machine)}[storing label in register]-->
-  <!-- \indcodeplus{goto}{(in register machine)}[label as destination]-->
-  To reflect this ability, we will extend the <SCHEMEINLINE>assign</SCHEMEINLINE>
-  instruction of the register-machine language to allow a register to be
-  assigned as value a label from the controller sequence (as a special
-  kind of constant).  We will also extend the <SPLITINLINE><SCHEME><SCHEMEINLINE>goto</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> instruction to
-  allow execution to continue at the entry point described by the
-  contents of a register rather than only at an entry point described by
-  a constant label.  Using these new constructs we can terminate the
-  <SCHEMEINLINE>gcd</SCHEMEINLINE> subroutine with a branch to the location stored in the <SCHEMEINLINE>continue</SCHEMEINLINE> register.  This leads to the controller sequence shown in
-  figure<SPACE/><REF NAME="fig:gcd-mach-2labels"/>.
-      </TEXT>
+  <TEXT>
+    This is a reasonable approach for handling small problems, but it would be
+    awkward if there were many instances of GCD computations in the controller
+    sequence.  To decide where to continue executing after the
+    <SCHEMEINLINE>gcd</SCHEMEINLINE> subroutine, we would need tests in the data
+    paths and branch instructions in the controller for all the places that use
+    <SCHEMEINLINE>gcd</SCHEMEINLINE>. A more powerful method for implementing
+    subroutines is to have the <SCHEMEINLINE>continue</SCHEMEINLINE> register
+    hold the label of the entry point in the controller sequence at which
+    execution should continue when the subroutine is finished. Implementing this
+    strategy requires a new kind of connection between the data paths and the
+    controller of a register machine: There must be a way to assign to a
+    register a label in the controller sequence in such a way that this value
+    can be fetched from the register and used to continue execution at the
+    designated entry point.
+  </TEXT>
 
-      <TEXT>
-  A machine with more than one subroutine could use multiple
-  continuation registers (e.g., <SCHEMEINLINE>gcd-continue</SCHEMEINLINE>, <SCHEMEINLINE>factorial-continue</SCHEMEINLINE>) or we could have all subroutines share a single
-  <SCHEMEINLINE>continue</SCHEMEINLINE> register.  Sharing is more economical, but we must be
-  careful if we have a subroutine (<SCHEMEINLINE>sub1</SCHEMEINLINE>) that calls another
-  subroutine (<SCHEMEINLINE>sub2</SCHEMEINLINE>).  Unless <SCHEMEINLINE>sub1</SCHEMEINLINE> saves the contents of <SCHEMEINLINE>continue</SCHEMEINLINE> in some other register before setting up <SCHEMEINLINE>continue</SCHEMEINLINE> for
-  the call to <SCHEMEINLINE>sub2</SCHEMEINLINE>, <SCHEMEINLINE>sub1</SCHEMEINLINE> will not know where to go when it
-  is finished.  The mechanism developed in the next section to handle
-  recursion also provides a better solution to this problem of nested
-  subroutine calls.
-  <INDEX>register machine<SUBINDEX>subroutine|)</SUBINDEX></INDEX>
-  <INDEX>subroutine in register machine|)</INDEX>
-      </TEXT>
+  <TEXT>
+    <!-- \indcodeplus{assign}{(in register machine)}[storing label in register]
+    -->
+    <!-- \indcodeplus{goto}{(in register machine)}[label as destination]
+    -->
+    To reflect this ability, we will extend the
+    <SCHEMEINLINE>assign</SCHEMEINLINE>
+    instruction of the register-machine language to allow a register to be
+    assigned as value a label from the controller sequence (as a special
+    kind of constant).  We will also extend the
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>goto</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    instruction to allow execution to continue at the entry point described by
+    the contents of a register rather than only at an entry point described by
+    a constant label.  Using these new constructs we can terminate the
+    <SCHEMEINLINE>gcd</SCHEMEINLINE> subroutine with a branch to the location
+    stored in the <SCHEMEINLINE>continue</SCHEMEINLINE> register.  This leads
+    to the controller sequence shown in
+    figure<SPACE/><REF NAME="fig:gcd-mach-2labels"/>.
+  </TEXT>
 
-    </SUBSECTION>
+  <TEXT>
+    A machine with more than one subroutine could use multiple
+    continuation registers (e.g., <SCHEMEINLINE>gcd-continue</SCHEMEINLINE>,
+    <SCHEMEINLINE>factorial-continue</SCHEMEINLINE>) or we could have all
+    subroutines share a single
+    <SCHEMEINLINE>continue</SCHEMEINLINE> register.  Sharing is more economical,
+    but we must be careful if we have a subroutine
+    (<SCHEMEINLINE>sub1</SCHEMEINLINE>) that calls another subroutine
+    (<SCHEMEINLINE>sub2</SCHEMEINLINE>).  Unless
+    <SCHEMEINLINE>sub1</SCHEMEINLINE> saves the contents of
+    <SCHEMEINLINE>continue</SCHEMEINLINE> in some other register before setting
+    up <SCHEMEINLINE>continue</SCHEMEINLINE> for the call to
+    <SCHEMEINLINE>sub2</SCHEMEINLINE>, <SCHEMEINLINE>sub1</SCHEMEINLINE> will
+    not know where to go when it is finished.  The mechanism developed in the
+    next section to handle recursion also provides a better solution to this
+    problem of nested subroutine calls.
+    <INDEX>register machine<SUBINDEX>subroutine|)</SUBINDEX></INDEX>
+    <INDEX>subroutine in register machine|)</INDEX>
+  </TEXT>
+</SUBSECTION>
diff --git a/xml/chapter5/section1/subsection4.xml b/xml/chapter5/section1/subsection4.xml
index 60cb6ed52..55fa7cf92 100644
--- a/xml/chapter5/section1/subsection4.xml
+++ b/xml/chapter5/section1/subsection4.xml
@@ -1,235 +1,319 @@
-    <SUBSECTION>
-      <NAME>
-  Using a Stack to Implement Recursion
-      </NAME>
+<SUBSECTION>
+  <NAME>
+    Using a Stack to Implement Recursion
+  </NAME>
 
-      <LABEL NAME="sec:stack-recursion"/>
-      <INDEX>stack<SUBINDEX>recursion@for recursion in register machine|(</SUBINDEX></INDEX>
-      <INDEX>register machine<SUBINDEX>stack|(</SUBINDEX></INDEX>
-      <INDEX>recursive process<SUBINDEX>register machine for|(</SUBINDEX></INDEX>
+  <LABEL NAME="sec:stack-recursion"/>
+  <INDEX>stack
+  <SUBINDEX>recursion@for recursion in register machine|(</SUBINDEX></INDEX>
+  <INDEX>register machine<SUBINDEX>stack|(</SUBINDEX></INDEX>
+  <INDEX>recursive process<SUBINDEX>register machine for|(</SUBINDEX></INDEX>
 
-      <TEXT>
-  <INDEX>iterative process<SUBINDEX>register machine for</SUBINDEX></INDEX>
-  With the ideas illustrated so far, we can implement any iterative
-  process by specifying a register machine that has a register
-  corresponding to each state variable of the process.  The machine
-  repeatedly executes a controller loop, changing the contents
-  of the registers, until some termination condition is satisfied.  At
-  each point in the controller sequence, the state of the machine
-  (representing the state of the iterative process) is completely
-  determined by the contents of the registers (the values of the state
-  variables).
-      </TEXT>
+  <TEXT>
+    <INDEX>iterative process<SUBINDEX>register machine for</SUBINDEX></INDEX>
+    With the ideas illustrated so far, we can implement any iterative
+    process by specifying a register machine that has a register
+    corresponding to each state variable of the process.  The machine
+    repeatedly executes a controller loop, changing the contents
+    of the registers, until some termination condition is satisfied.  At
+    each point in the controller sequence, the state of the machine
+    (representing the state of the iterative process) is completely
+    determined by the contents of the registers (the values of the state
+    variables).
+  </TEXT>
 
-      <TEXT>
-  <INDEX>recursive process<SUBINDEX>iterative process vs.</SUBINDEX></INDEX>
-  <INDEX>iterative process<SUBINDEX>recursive process vs.</SUBINDEX></INDEX>
-  <!--  \indcode{factorial}[register machine for (recursive)|(] -->
-  Implementing recursive processes, however, requires an additional
-  mechanism.  Consider the following recursive method for computing
-  factorials, which we first examined in
-  section<SPACE/><REF NAME="sec:recursion-and-iteration"/>:
-
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    <INDEX>recursive process<SUBINDEX>iterative process vs.</SUBINDEX></INDEX>
+    <INDEX>iterative process<SUBINDEX>recursive process vs.</SUBINDEX></INDEX>
+    <!--  \indcode{factorial}[register machine for (recursive)|(] -->
+    Implementing recursive processes, however, requires an additional
+    mechanism.  Consider the following recursive method for computing
+    factorials, which we first examined in
+    section<SPACE/><REF NAME="sec:recursion-and-iteration"/>:
+    <SNIPPET>
+      <NAME>factorial_5_1_4</NAME>
+      <EXAMPLE>factorial_example</EXAMPLE>
+      <SCHEME>
       (define (factorial n)
       (if (= n 1)
       1
       (* (factorial (- n 1)) n)))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function factorial(n) {
     return n === 1 
            ? 1
            : n * factorial(n - 1);
 }      
-    </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  As we see from the
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, computing <LATEXINLINE>$n!$</LATEXINLINE> requires computing
-  <LATEXINLINE>$(n-1)!$</LATEXINLINE>.  Our GCD machine, modeled on the
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    As we see from the
+    <SPLITINLINE>
+      <SCHEME>procedure,</SCHEME>
+      <JAVASCRIPT>function,</JAVASCRIPT>
+    </SPLITINLINE>
+    computing <LATEXINLINE>$n!$</LATEXINLINE> requires computing
+    <LATEXINLINE>$(n-1)!$</LATEXINLINE>.  Our GCD machine, modeled on the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET PAGE="49" HIDE="yes">
+      <NAME>gcd_5_1_4_example</NAME>
+      <EXPECTED>4</EXPECTED>
+      <SCHEME>
+(gcd 20 12)
+      </SCHEME>
+      <JAVASCRIPT>
+gcd(20, 12);
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>gcd_5_1_4</NAME>
+      <EXAMPLE>gcd_5_1_4_example</EXAMPLE>
+      <SCHEME>
       (define (gcd a b)
       (if (= b 0)
       a
       (gcd b (remainder a b))))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function gcd(a, b) {
     return b === 0 ? a : gcd(b, a % b);
 }
-    </JAVASCRIPT>
-  </SNIPPET>
+      </JAVASCRIPT>
+    </SNIPPET>
 
-  similarly had to compute another GCD.  But there is an important
-  difference between the <SCHEMEINLINE>gcd</SCHEMEINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, which reduces the original
-  computation to a new GCD computation, and <SCHEMEINLINE>factorial</SCHEMEINLINE>, which
-  requires computing another factorial as a subproblem.  In GCD, the
-  answer to the new GCD computation is the answer to the original
-  problem.  To compute the next GCD, we simply place the new arguments
-  in the input registers of the GCD machine and reuse the
-  machine<APOS/>s data paths by executing the same controller sequence.  When
-  the machine is finished solving the final GCD problem, it has
-  completed the entire computation.
-      </TEXT>
+    similarly had to compute another GCD.  But there is an important
+    difference between the <SCHEMEINLINE>gcd</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure,</SCHEME>
+      <JAVASCRIPT>function,</JAVASCRIPT>
+    </SPLITINLINE>
+    which reduces the original computation to a new GCD computation, and
+    <SCHEMEINLINE>factorial</SCHEMEINLINE>, which requires computing another
+    factorial as a subproblem.  In GCD, the answer to the new GCD computation is
+    the answer to the original problem.  To compute the next GCD, we simply
+    place the new arguments in the input registers of the GCD machine and reuse
+    the machine<APOS/>s data paths by executing the same controller sequence.
+    When the machine is finished solving the final GCD problem, it has completed
+    the entire computation.
+  </TEXT>
 
-      <TEXT>
-  In the case of factorial (or any recursive process) the answer to the
-  new factorial subproblem is not the answer to the original problem.
-  The value obtained for <LATEXINLINE>$(n-1)!$</LATEXINLINE> must be multiplied by <LATEXINLINE>$n$</LATEXINLINE> to get the
-  final answer.  If we try to imitate the GCD design, and solve
-  the factorial subproblem by decrementing the <SCHEMEINLINE>n</SCHEMEINLINE> register and
-  rerunning the factorial machine, we will no longer have available the
-  old value of <SCHEMEINLINE>n</SCHEMEINLINE> by which to multiply the result.  We thus need a
-  second factorial machine to work on the subproblem.  This second
-  factorial computation itself has a factorial subproblem, which
-  requires a third factorial machine, and so on.  Since each factorial
-  machine contains another factorial machine within it, the total
-  machine contains an infinite nest of similar machines and hence cannot
-  be constructed from a fixed, finite number of parts.
-      </TEXT>
+  <TEXT>
+    In the case of factorial (or any recursive process) the answer to the
+    new factorial subproblem is not the answer to the original problem.
+    The value obtained for <LATEXINLINE>$(n-1)!$</LATEXINLINE> must be
+    multiplied by <LATEXINLINE>$n$</LATEXINLINE> to get the final answer.  If
+    we try to imitate the GCD design, and solve the factorial subproblem by
+    decrementing the <SCHEMEINLINE>n</SCHEMEINLINE> register and rerunning the
+    factorial machine, we will no longer have available the old value of
+    <SCHEMEINLINE>n</SCHEMEINLINE> by which to multiply the result.  We thus
+    need a second factorial machine to work on the subproblem.  This second
+    factorial computation itself has a factorial subproblem, which
+    requires a third factorial machine, and so on.  Since each factorial
+    machine contains another factorial machine within it, the total
+    machine contains an infinite nest of similar machines and hence cannot
+    be constructed from a fixed, finite number of parts.
+  </TEXT>
 
-      <TEXT>
-  Nevertheless, we can implement the factorial process as a register
-  machine if we can arrange to use the same components for each nested
-  instance of the machine.  Specifically, the machine that computes <LATEXINLINE>$n!$</LATEXINLINE>
-  should use the same components to work on the subproblem of computing
-  <LATEXINLINE>$(n-1)!$</LATEXINLINE>, on the subproblem for <LATEXINLINE>$(n-2)!$</LATEXINLINE>, and so on.  This is
-  plausible because, although the factorial process dictates that an
-  unbounded number of copies of the same machine are needed to perform a
-  computation, only one of these copies needs to be active at any given
-  time.  When the machine encounters a recursive subproblem, it can
-  suspend work on the main problem, reuse the same physical parts to
-  work on the subproblem, then continue the suspended computation.
-      </TEXT>
+  <TEXT>
+    Nevertheless, we can implement the factorial process as a register
+    machine if we can arrange to use the same components for each nested
+    instance of the machine.  Specifically, the machine that computes
+    <LATEXINLINE>$n!$</LATEXINLINE>
+    should use the same components to work on the subproblem of computing
+    <LATEXINLINE>$(n-1)!$</LATEXINLINE>, on the subproblem for
+    <LATEXINLINE>$(n-2)!$</LATEXINLINE>, and so on.  This is
+    plausible because, although the factorial process dictates that an
+    unbounded number of copies of the same machine are needed to perform a
+    computation, only one of these copies needs to be active at any given
+    time.  When the machine encounters a recursive subproblem, it can
+    suspend work on the main problem, reuse the same physical parts to
+    work on the subproblem, then continue the suspended computation.
+  </TEXT>
 
-      <TEXT>
-  In the subproblem, the contents of the registers will be different
-  than they were in the main problem. (In this case the <SCHEMEINLINE>n</SCHEMEINLINE> register
-  is decremented.)  In order to be able to continue the suspended
-  computation, the machine must save the contents of any registers that
-  will be needed after the subproblem is solved so that these can be
-  restored to continue the suspended computation.  In the case of
-  factorial, we will save the old value of <SCHEMEINLINE>n</SCHEMEINLINE>, to be restored when
-  we are finished computing the factorial of the decremented <SCHEMEINLINE>n</SCHEMEINLINE>
-  register.<FOOTNOTE>One might argue that we don<APOS/>t need to save the old
-    <SCHEMEINLINE>n</SCHEMEINLINE>; after we decrement it and solve the subproblem, we could
-    simply increment it to recover the old value.  Although this strategy
-    works for factorial, it cannot work in general, since the old value of
-    a register cannot always be computed from the new one.</FOOTNOTE>
-      </TEXT>
+  <TEXT>
+    In the subproblem, the contents of the registers will be different
+    than they were in the main problem. (In this case the
+    <SCHEMEINLINE>n</SCHEMEINLINE> register is decremented.)  In order to be
+    able to continue the suspended computation, the machine must save the
+    contents of any registers that will be needed after the subproblem is
+    solved so that these can be restored to continue the suspended computation.
+    In the case of factorial, we will save the old value of
+    <SCHEMEINLINE>n</SCHEMEINLINE>, to be restored when we are finished
+    computing the factorial of the decremented <SCHEMEINLINE>n</SCHEMEINLINE>
+    register.<FOOTNOTE>One might argue that we don<APOS/>t need to save the old
+    <SCHEMEINLINE>n</SCHEMEINLINE>; after we decrement it and solve the
+    subproblem, we could simply increment it to recover the old value.  Although
+    this strategy works for factorial, it cannot work in general, since the old
+    value of a register cannot always be computed from the new one.</FOOTNOTE>
+  </TEXT>
 
-      <TEXT>
-  Since there is no <EM>a priori</EM> limit on the depth of nested
-  recursive calls, we may need to save an arbitrary number of register
-  values.  These values must be restored in the reverse of the order in
-  which they were saved, since in a nest of recursions the last
-  subproblem to be entered is the first to be finished.  This dictates
-  the use of a <EM>stack</EM>, or <QUOTE>last in, first out</QUOTE> data structure, to
-  save register values.  We can extend the register-machine language to
-  include a stack by adding two kinds of instructions: Values are placed
-  <INDEX>register-machine language<SUBINDEX>save@<SCHEMEINLINE>save</SCHEMEINLINE></SUBINDEX></INDEX>
-  <!-- \indcodeplus{save}{(in register machine)}-->
-  <INDEX>register-machine language<SUBINDEX>restore@<SCHEMEINLINE>restore</SCHEMEINLINE></SUBINDEX></INDEX>
-  <!-- \indcodeplus{restore}{(in register machine)}-->
-  on the stack using a <SCHEMEINLINE>save</SCHEMEINLINE> instruction and restored from the
-  stack using a <SCHEMEINLINE>restore</SCHEMEINLINE> instruction.  After a sequence of values
-  has been <SCHEMEINLINE>save</SCHEMEINLINE>d on the stack, a sequence of <SCHEMEINLINE>restore</SCHEMEINLINE>s will
-  retrieve these values in reverse order.<FOOTNOTE>In
-    section<SPACE/><REF NAME="sec:storage-allocation"/> we will see how to implement a
-    stack in terms of more primitive operations.</FOOTNOTE>
-      </TEXT>
+  <TEXT>
+    Since there is no <EM>a priori</EM> limit on the depth of nested
+    recursive calls, we may need to save an arbitrary number of register
+    values.  These values must be restored in the reverse of the order in
+    which they were saved, since in a nest of recursions the last
+    subproblem to be entered is the first to be finished.  This dictates
+    the use of a <EM>stack</EM>, or <QUOTE>last in, first out</QUOTE> data
+    structure, to save register values.  We can extend the register-machine
+    language to include a stack by adding two kinds of instructions: Values are
+    placed
+    <INDEX>register-machine language
+    <SUBINDEX>save@<SCHEMEINLINE>save</SCHEMEINLINE></SUBINDEX></INDEX>
+    <!-- \indcodeplus{save}{(in register machine)}-->
+    <INDEX>register-machine language
+    <SUBINDEX>restore@<SCHEMEINLINE>restore</SCHEMEINLINE></SUBINDEX></INDEX>
+    <!-- \indcodeplus{restore}{(in register machine)}-->
+    on the stack using a <SCHEMEINLINE>save</SCHEMEINLINE> instruction and
+    restored from the stack using a <SCHEMEINLINE>restore</SCHEMEINLINE>
+    instruction.  After a sequence of values has been
+    <SCHEMEINLINE>save</SCHEMEINLINE>d on the stack, a sequence of
+    <SCHEMEINLINE>restore</SCHEMEINLINE>s will retrieve these values in reverse
+    order.<FOOTNOTE>In section<SPACE/><REF NAME="sec:storage-allocation"/> we
+    will see how to implement a stack in terms of more primitive
+    operations.</FOOTNOTE>
+  </TEXT>
 
-      <TEXT>
-  With the aid of the stack, we can reuse a single copy of the factorial
-  machine<APOS/>s data paths for each factorial subproblem.  There is a
-  similar design issue in reusing the controller sequence that operates
-  the data paths.  To reexecute the factorial computation, the
-  controller cannot simply loop back to the beginning, as with
-  an iterative process, because after solving the <LATEXINLINE>$(n-1)!$</LATEXINLINE> subproblem
-  the machine must still multiply the result by <LATEXINLINE>$n$</LATEXINLINE>.  The controller
-  must suspend its computation of <LATEXINLINE>$n!$</LATEXINLINE>, solve the <LATEXINLINE>$(n-1)!$</LATEXINLINE> subproblem,
-  then continue its computation of <LATEXINLINE>$n!$</LATEXINLINE>.  This view of the factorial
-  computation suggests the use of the subroutine mechanism described in
-  section<SPACE/><REF NAME="sec:subroutines"/>, which has the controller use a
-  <!-- \indcodeplus{continue}{register}[recursion and]-->
-  <SCHEMEINLINE>continue</SCHEMEINLINE> register to transfer to the part of the sequence that
-  solves a subproblem and then continue where it left off on the main
-  problem.  We can thus make a factorial subroutine that returns to the
-  entry point stored in the <SCHEMEINLINE>continue</SCHEMEINLINE> register.  Around each subroutine
-  call, register, since each <QUOTE>level</QUOTE> of the factorial computation will use
-  the same <SCHEMEINLINE>continue</SCHEMEINLINE> register.  That is, the factorial subroutine
-  must put a new value in <SCHEMEINLINE>continue</SCHEMEINLINE> when it calls itself for a
-  subproblem, but it will need the old value in order to return to the
-  place that called it to solve a subproblem.
-      </TEXT>
+  <TEXT>
+    With the aid of the stack, we can reuse a single copy of the factorial
+    machine<APOS/>s data paths for each factorial subproblem.  There is a
+    similar design issue in reusing the controller sequence that operates
+    the data paths.  To reexecute the factorial computation, the
+    controller cannot simply loop back to the beginning, as with
+    an iterative process, because after solving the
+    <LATEXINLINE>$(n-1)!$</LATEXINLINE> subproblem
+    the machine must still multiply the result by
+    <LATEXINLINE>$n$</LATEXINLINE>.  The controller
+    must suspend its computation of <LATEXINLINE>$n!$</LATEXINLINE>, solve the
+    <LATEXINLINE>$(n-1)!$</LATEXINLINE> subproblem,
+    then continue its computation of <LATEXINLINE>$n!$</LATEXINLINE>.  This
+    view of the factorial computation suggests the use of the subroutine
+    mechanism described in section<SPACE/><REF NAME="sec:subroutines"/>, which
+    has the controller use a
+    <!-- \indcodeplus{continue}{register}[recursion and]-->
+    <SCHEMEINLINE>continue</SCHEMEINLINE> register to transfer to the part of
+    the sequence that solves a subproblem and then continue where it left off
+    on the main problem.  We can thus make a factorial subroutine that returns
+    to the entry point stored in the <SCHEMEINLINE>continue</SCHEMEINLINE>
+    register.  Around each subroutine call, register, since each
+    <QUOTE>level</QUOTE> of the factorial computation will use the same
+    <SCHEMEINLINE>continue</SCHEMEINLINE> register.  That is, the factorial
+    subroutine must put a new value in <SCHEMEINLINE>continue</SCHEMEINLINE>
+    when it calls itself for a subproblem, but it will need the old value in
+    order to return to the place that called it to solve a subproblem.
+  </TEXT>
 
-      <TEXT>
-  Figure<SPACE/><REF NAME="fig:fact-machine"/> shows the data paths and controller for
-  a machine that implements the recursive <SCHEMEINLINE>factorial</SCHEMEINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.
-  The machine has a stack and three registers, called <SCHEMEINLINE>n</SCHEMEINLINE>, <SCHEMEINLINE>val</SCHEMEINLINE>, and <SCHEMEINLINE>continue</SCHEMEINLINE>.  To simplify the data-path diagram, we have
-  not named the register-assignment buttons, only the stack-operation
-  buttons (<SCHEMEINLINE>sc</SCHEMEINLINE> and <SCHEMEINLINE>sn</SCHEMEINLINE> to save registers, <SCHEMEINLINE>rc</SCHEMEINLINE> and <SCHEMEINLINE>rn</SCHEMEINLINE> to restore registers).  To operate the machine, we put in register
-  <SCHEMEINLINE>n</SCHEMEINLINE> the number whose factorial we wish to compute and start the
-  machine.  When the machine reaches <SCHEMEINLINE>fact-done</SCHEMEINLINE>, the computation is
-  finished and the answer will be found in the <SCHEMEINLINE>val</SCHEMEINLINE> register.  In
-  the controller sequence, <SCHEMEINLINE>n</SCHEMEINLINE> and <SCHEMEINLINE>continue</SCHEMEINLINE> are saved before
-  each recursive call and restored upon return from the call.  Returning
-  from a call is accomplished by branching to the location stored in
-  <SCHEMEINLINE>continue</SCHEMEINLINE>.  <SCHEMEINLINE>Continue</SCHEMEINLINE> is initialized when the machine starts
-  so that the last return will go to <SCHEMEINLINE>fact-done</SCHEMEINLINE>.  The <SCHEMEINLINE>val</SCHEMEINLINE>
-  register, which holds the result of the factorial computation, is not
-  saved before the recursive call, because the old contents of <SCHEMEINLINE>val</SCHEMEINLINE>
-  is not useful after the subroutine returns.  Only the new value, which
-  is the value produced by the subcomputation, is needed.
-  <!--  \indcode{factorial}[register machine for (recursive)|)] -->
-      </TEXT>
+  <TEXT>
+    <SPLITINLINE>
+      <SCHEME>
+	Figure<SPACE/><REF NAME="fig:fact-machine_scheme"/>
+      </SCHEME>
+      <JAVASCRIPT>
+	Figure<SPACE/><REF NAME="fig:fact-machine"/>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    shows the data paths and controller for
+    a machine that implements the recursive
+    <SCHEMEINLINE>factorial</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+      <JAVASCRIPT>function.</JAVASCRIPT>
+    </SPLITINLINE>
+    The machine has a stack and three registers, called
+    <SCHEMEINLINE>n</SCHEMEINLINE>, <SCHEMEINLINE>val</SCHEMEINLINE>, and
+    <SCHEMEINLINE>continue</SCHEMEINLINE>.  To simplify the data-path diagram,
+    we have not named the register-assignment buttons, only the stack-operation
+    buttons (<SCHEMEINLINE>sc</SCHEMEINLINE> and <SCHEMEINLINE>sn</SCHEMEINLINE>
+    to save registers, <SCHEMEINLINE>rc</SCHEMEINLINE> and
+    <SCHEMEINLINE>rn</SCHEMEINLINE> to restore registers).  To operate the
+    machine, we put in register <SCHEMEINLINE>n</SCHEMEINLINE> the number whose
+    factorial we wish to compute and start the machine.  When the machine
+    reaches <SCHEMEINLINE>fact-done</SCHEMEINLINE>, the computation is finished
+    and the answer will be found in the <SCHEMEINLINE>val</SCHEMEINLINE>
+    register.  In the controller sequence, <SCHEMEINLINE>n</SCHEMEINLINE> and
+    <SCHEMEINLINE>continue</SCHEMEINLINE> are saved before each recursive call
+    and restored upon return from the call.  Returning from a call is
+    accomplished by branching to the location stored in
+    <SCHEMEINLINE>continue</SCHEMEINLINE>. 
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Continue</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The register
+	<JAVASCRIPTINLINE>continue</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is initialized when the machine starts so that the last return will go to
+    <SCHEMEINLINE>fact-done</SCHEMEINLINE>.  The
+    <SCHEMEINLINE>val</SCHEMEINLINE>
+    register, which holds the result of the factorial computation, is not
+    saved before the recursive call, because the old contents of
+    <SCHEMEINLINE>val</SCHEMEINLINE> is not useful after the subroutine returns.
+    Only the new value, which is the value produced by the subcomputation, is
+    needed.
+    <!--  \indcode{factorial}[register machine for (recursive)|)] -->
+  </TEXT>
 
-      <TEXT>
-  Although in principle the factorial computation requires an infinite
-  machine, the machine in Figure<SPACE/><REF NAME="fig:fact-machine"/> is actually
-  finite except for the stack, which is potentially unbounded.  Any
-  particular physical implementation of a stack, however, will be of
-  finite size, and this will limit the depth of recursive calls that can
-  be handled by the machine.  This implementation of factorial
-  illustrates the general strategy for realizing recursive algorithms as
-  ordinary register machines augmented by stacks.  When a recursive
-  subproblem is encountered, we save on the stack the registers whose
-  current values will be required after the subproblem is solved, solve
-  the recursive subproblem, then restore the saved registers and
-  continue execution on the main problem.  The <SCHEMEINLINE>continue</SCHEMEINLINE> register
-  must always be saved.  Whether there are other registers that need to
-  be saved depends on the particular machine, since not all recursive
-  computations need the original values of registers that are modified
-  during solution of the subproblem (see exercise<SPACE/><REF NAME="ex:design-reg-machines"/>).
-      </TEXT>
+  <TEXT>
+    Although in principle the factorial computation requires an infinite
+    machine, the machine in
+    <SPLITINLINE>
+      <SCHEME>
+	figure<SPACE/><REF NAME="fig:fact-machine_scheme"/>
+      </SCHEME>
+      <JAVASCRIPT>
+	figure<SPACE/><REF NAME="fig:fact-machine"/>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is actually finite except for the stack, which is potentially unbounded.  Any
+    particular physical implementation of a stack, however, will be of finite
+    size, and this will limit the depth of recursive calls that can be handled
+    by the machine.  This implementation of factorial illustrates the general
+    strategy for realizing recursive algorithms as ordinary register machines
+    augmented by stacks.  When a recursive subproblem is encountered, we save on
+    the stack the registers whose current values will be required after the
+    subproblem is solved, solve the recursive subproblem, then restore the saved
+    registers and continue execution on the main problem.  The
+    <SCHEMEINLINE>continue</SCHEMEINLINE> register must always be saved.
+    Whether there are other registers that need to be saved depends on the
+    particular machine, since not all recursive computations need the original
+    values of registers that are modified during solution of the subproblem
+    (see exercise<SPACE/><REF NAME="ex:design-reg-machines"/>).
+  </TEXT>
 
+  <SUBHEADING>
+    <NAME>A double recursion</NAME>
+  </SUBHEADING>
 
-      <SUBHEADING>
-  <NAME>A double recursion</NAME>
-      </SUBHEADING>
-
-      <TEXT>
-  <!--  \indcode{fib}[register machine for (tree-recursive)] -->
-  Let us examine a more complex recursive process, the tree-recursive
-  computation of the Fibonacci numbers, which we introduced in
-  section<SPACE/><REF NAME="sec:tree-recursion"/>:
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    <!--  \indcode{fib}[register machine for (tree-recursive)] -->
+    Let us examine a more complex recursive process, the tree-recursive
+    computation of the Fibonacci numbers, which we introduced in
+    section<SPACE/><REF NAME="sec:tree-recursion"/>:
+    <SNIPPET PAGE="37" HIDE="yes">
+      <NAME>fib_5_1_4_example</NAME>
+      <EXPECTED>8</EXPECTED>
+      <SCHEME>
+(fib 6)
+      </SCHEME>
+      <JAVASCRIPT>
+fib(6);
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>fib_5_1_4</NAME>
+      <EXAMPLE>fib_5_1_4_example</EXAMPLE>
+      <SCHEME>
       (define (fib n)
       (if (&lt; n 2)
       n
       (+ (fib (- n 1)) (fib (- n 2)))))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function fib(n) {
     return n === 0
            ? 0
@@ -237,43 +321,47 @@ function fib(n) {
              ? 1
              : fib(n - 1) + fib(n - 2);
 }
-    </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  Just as with factorial, we can implement the recursive Fibonacci
-  computation as a register machine with registers <SCHEMEINLINE>n</SCHEMEINLINE>, <SCHEMEINLINE>val</SCHEMEINLINE>,
-  and <SCHEMEINLINE>continue</SCHEMEINLINE>.  The machine is more complex than the one for
-  factorial, because there are two places in the controller sequence
-  where we need to perform recursive calls<EMDASH/>once to compute Fib<LATEXINLINE>$(n-1)$</LATEXINLINE>
-  and once to compute Fib<LATEXINLINE>$(n-2)$</LATEXINLINE>.  To set up for each of these calls, we
-  save the registers whose values will be needed later, set the <SCHEMEINLINE>n</SCHEMEINLINE>
-  register to the number whose Fib we need to compute recursively (<LATEXINLINE>$n-1$</LATEXINLINE>
-  or <LATEXINLINE>$n-2$</LATEXINLINE>), and assign to <SCHEMEINLINE>continue</SCHEMEINLINE> the entry point in the main sequence
-  to which to return (<SCHEMEINLINE>afterfib-n-1</SCHEMEINLINE> or <SCHEMEINLINE>afterfib-n-2</SCHEMEINLINE>,
-  respectively).  We then go to <SCHEMEINLINE>fib-loop</SCHEMEINLINE>.  When we return from the
-  recursive call, the answer is in <SCHEMEINLINE>val</SCHEMEINLINE>.
-  Figure<SPACE/><REF NAME="fig:fib-machine"/> shows the controller sequence for this
-  machine.
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-  <SPLIT>
-    <SCHEME>
-      <FIGURE src="img_original/Fig5.11b.std.svg">
-        <SNIPPET>
-          <SCHEME>
+  <TEXT>
+    Just as with factorial, we can implement the recursive Fibonacci
+    computation as a register machine with registers
+    <SCHEMEINLINE>n</SCHEMEINLINE>, <SCHEMEINLINE>val</SCHEMEINLINE>,
+    and <SCHEMEINLINE>continue</SCHEMEINLINE>.  The machine is more complex than
+    the one for factorial, because there are two places in the controller
+    sequence where we need to perform recursive calls<EMDASH/>once to compute
+    Fib<LATEXINLINE>$(n-1)$</LATEXINLINE> and once to compute
+    Fib<LATEXINLINE>$(n-2)$</LATEXINLINE>.  To set up for each of these calls,
+    we save the registers whose values will be needed later, set the
+    <SCHEMEINLINE>n</SCHEMEINLINE>
+    register to the number whose Fib we need to compute recursively
+    (<LATEXINLINE>$n-1$</LATEXINLINE> or <LATEXINLINE>$n-2$</LATEXINLINE>), and
+    assign to <SCHEMEINLINE>continue</SCHEMEINLINE> the entry point in the main
+    sequence to which to return (<SCHEMEINLINE>afterfib-n-1</SCHEMEINLINE> or
+    <SCHEMEINLINE>afterfib-n-2</SCHEMEINLINE>, respectively).  We then go to
+    <SCHEMEINLINE>fib-loop</SCHEMEINLINE>.  When we return from the
+    recursive call, the answer is in <SCHEMEINLINE>val</SCHEMEINLINE>.
+    Figure<SPACE/><REF NAME="fig:fib-machine"/> shows the controller sequence
+    for this machine.
+    <SPLIT>
+      <SCHEME>
+	<FIGURE src="img_original/Fig5.11b.std.svg">
+          <SNIPPET>
+            <SCHEME>
     <!-- 
         %(registers n val continue)
         %(operations * - =)
       -->
       (controller
-      (assign continue (label fact-done))     <EM>; set up final return address</EM>
+      (assign continue (label fact-done))     ; set up final return address
       fact-loop
       (test (op =) (reg n) (const 1))
       (branch (label base-case))
-      <EM>;; Set up for the recursive call by saving <SCHEMEINLINE>n</SCHEMEINLINE> and <SCHEMEINLINE>continue</SCHEMEINLINE>.</EM>
-      <EM>;; Set up <SCHEMEINLINE>continue</SCHEMEINLINE> so that the computation will continue</EM>
-      <EM>;; at <SCHEMEINLINE>after-fact</SCHEMEINLINE> when the subroutine returns.</EM>
+      ;; Set up for the recursive call by saving n and continue.
+      ;; Set up continue so that the computation will continue
+      ;; at after-fact when the subroutine returns.
       (save continue)
       (save n)
       (assign n (op -) (reg n) (const 1))
@@ -288,18 +376,18 @@ function fib(n) {
       (assign val (const 1))                  ; ^base case: $1!=1$^
       (goto (reg continue))                   ; ^return to caller^
       fact-done)
-          </SCHEME>
-        </SNIPPET>
-        <CAPTION>A recursive factorial machine.</CAPTION>
-        <!--  \indcode{factorial}[register machine for (recursive)] -->
-        <LABEL NAME="fig:fact-machine"/>
-      </FIGURE>
-    </SCHEME>
-    <JAVASCRIPT>
-      <FIGURE> 
-	<FIGURE src="img_javascript/Fig5.11b.std.svg"/> 
-        <SNIPPET>
-          <JAVASCRIPT>
+            </SCHEME>
+          </SNIPPET>
+          <CAPTION>A recursive factorial machine.</CAPTION>
+          <!--  \indcode{factorial}[register machine for (recursive)] -->
+          <LABEL NAME="fig:fact-machine_scheme"/>
+	</FIGURE>
+      </SCHEME>
+      <JAVASCRIPT>
+	<FIGURE> 
+	  <FIGURE src="img_javascript/Fig5.11b.std.svg"/> 
+          <SNIPPET>
+            <JAVASCRIPT>
 controller(
     list(      
        assign("continue", label("fact-done")), // set up final return address
@@ -324,22 +412,18 @@ controller(
        assign("val", constant(1)),       // base case: val = 1
        go_to(reg("continue")),        // return to caller
        "fact-done"));
-          </JAVASCRIPT>
-        </SNIPPET>
-        <CAPTION>A recursive factorial machine.</CAPTION>
-        <!--  \indcode{factorial}[register machine for (recursive)] -->
-        <LABEL NAME="fig:fact-machine"/>
-      </FIGURE>
-    </JAVASCRIPT>
-  </SPLIT>
-
-  <FIGURE>
-  <SNIPPET EVAL="no">
-    <!-- 
-        %(registers n val continue)
-        %(operations &lt; - +)
-      -->
-    <SCHEME>
+            </JAVASCRIPT>
+          </SNIPPET>
+          <CAPTION>A recursive factorial machine.</CAPTION>
+          <!--  \indcode{factorial}[register machine for (recursive)] -->
+          <LABEL NAME="fig:fact-machine"/>
+	</FIGURE>
+      </JAVASCRIPT>
+    </SPLIT>
+    <!--  %(registers n val continue) %(operations &lt; - +) -->
+    <FIGURE>
+      <SNIPPET EVAL="no">
+	<SCHEME>
       (controller
       (assign continue (label fib-done))
       fib-loop
@@ -371,8 +455,8 @@ controller(
       (assign val (reg n))                ; base case: ^${\textrm{Fib}}(n)=n$^
       (goto (reg continue))
       fib-done)
-    </SCHEME>
-    <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 controller(
     list(      
        assign("continue", label("fib-done")),
@@ -406,51 +490,69 @@ controller(
        assign("val", reg("n")),    // base case: Fib(n) = n
        go_to(reg("continue")),
        "fib-done"));
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>Controller for a machine to compute Fibonacci numbers.</CAPTION>
-  <LABEL NAME="fig:fib-machine"/>
-  </FIGURE>
-      </TEXT>
-
-      <EXERCISE><LABEL NAME="ex:design-reg-machines"/>
-  Specify register machines that implement each of the following
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>.  For each machine, write a controller instruction sequence
-  and draw a diagram showing the data paths.
-  <OL>
-    <LI>
-      Recursive exponentiation:
+	</JAVASCRIPT>
+      </SNIPPET>
+      <CAPTION>Controller for a machine to compute Fibonacci numbers.</CAPTION>
+      <LABEL NAME="fig:fib-machine"/>
+    </FIGURE>
+  </TEXT>
 
-      <SNIPPET>
-        <SCHEME>
-    <!--  \indcode{expt}[register machine for] -->
+  <EXERCISE>
+    <LABEL NAME="ex:design-reg-machines"/>
+    Specify register machines that implement each of the following
+    <SPLITINLINE>
+      <SCHEME>procedures.</SCHEME>
+      <JAVASCRIPT>functions.</JAVASCRIPT>
+    </SPLITINLINE>
+    For each machine, write a controller instruction sequence
+    and draw a diagram showing the data paths.
+    <OL>
+      <LI>
+	Recursive exponentiation:
+	<!--  \indcode{expt}[register machine for] -->
+	<SNIPPET>
+	  <NAME>expt_5_1_4</NAME>
+	  <EXAMPLE>expt_5_1_4_example</EXAMPLE>
+          <SCHEME>
     (define (expt b n)
     (if (= n 0)
     1
     (* b (expt b (- n 1)))))
-        </SCHEME>
-	<JAVASCRIPT>
+          </SCHEME>
+	  <JAVASCRIPT>
 function expt(b, n) {
     return n === 0
         ? 1
         : b * expt(b, n - 1);
 }
-	</JAVASCRIPT>
-      </SNIPPET>
-    </LI>
-    <LI>
-      Iterative exponentiation:
+	  </JAVASCRIPT>
+	</SNIPPET>
+      </LI>
+      <LI>
+	Iterative exponentiation:
 
-      <SNIPPET>
-        <SCHEME>
+	<SNIPPET PAGE="44" HIDE="yes">
+	  <NAME>expt_5_1_4_example</NAME>
+	  <EXPECTED>81</EXPECTED>
+	  <SCHEME>
+(expt 3 4)
+	  </SCHEME>
+	  <JAVASCRIPT>
+expt(3, 4);
+	  </JAVASCRIPT>
+	</SNIPPET>
+	<SNIPPET>
+	  <NAME>expt_iterative_5_1_4</NAME>
+	  <EXAMPLE>expt_5_1_4_example</EXAMPLE>
+          <SCHEME>
     (define (expt b n)
     (define (expt-iter counter product)
     (if (= counter 0)
     product
     (expt-iter (- counter 1) (* b product))))
     (expt-iter n 1))
-        </SCHEME>
-	<JAVASCRIPT>
+          </SCHEME>
+	  <JAVASCRIPT>
 function expt(b, n) {	  
     function expt_iter(counter, product) {
         return counter === 0
@@ -459,27 +561,28 @@ function expt(b, n) {
     }
     return expt_iter(n, 1);
 }
-	</JAVASCRIPT>
-      </SNIPPET>
-    </LI>
-  </OL>
-      </EXERCISE>
-
-      <EXERCISE>
-  Hand-simulate the factorial and Fibonacci machines, using some
-  nontrivial input (requiring execution of at least one recursive call).
-  Show the contents of the stack at each significant point in the
-  execution.
-  <LABEL NAME="ex:hand-sim"/>
-      </EXERCISE>
+	  </JAVASCRIPT>
+	</SNIPPET>
+      </LI>
+    </OL>
+  </EXERCISE>
 
-      <EXERCISE>
-  Ben Bitdiddle observes that the Fibonacci machine<APOS/>s controller sequence
-  has an extra <SCHEMEINLINE>save</SCHEMEINLINE> and an extra <SCHEMEINLINE>restore</SCHEMEINLINE>, which can be
-  removed to make a faster machine.  Where are these instructions?
-      </EXERCISE>
-      <INDEX>stack<SUBINDEX>recursion@for recursion in register machine|)</SUBINDEX></INDEX>
-      <INDEX>register machine<SUBINDEX>stack|)</SUBINDEX></INDEX>
-      <INDEX>recursive process<SUBINDEX>register machine for|)</SUBINDEX></INDEX>
+  <EXERCISE>
+    Hand-simulate the factorial and Fibonacci machines, using some
+    nontrivial input (requiring execution of at least one recursive call).
+    Show the contents of the stack at each significant point in the
+    execution.
+    <LABEL NAME="ex:hand-sim"/>
+  </EXERCISE>
 
-    </SUBSECTION>
+  <EXERCISE>
+    Ben Bitdiddle observes that the Fibonacci machine<APOS/>s controller sequence
+    has an extra <SCHEMEINLINE>save</SCHEMEINLINE> and an extra
+    <SCHEMEINLINE>restore</SCHEMEINLINE>, which can be removed to make a faster
+    machine.  Where are these instructions?
+  </EXERCISE>
+  <INDEX>stack
+  <SUBINDEX>recursion@for recursion in register machine|)</SUBINDEX></INDEX>
+  <INDEX>register machine<SUBINDEX>stack|)</SUBINDEX></INDEX>
+  <INDEX>recursive process<SUBINDEX>register machine for|)</SUBINDEX></INDEX>
+</SUBSECTION>
diff --git a/xml/chapter5/section1/subsection5.xml b/xml/chapter5/section1/subsection5.xml
index 62314a1b1..cad94505e 100644
--- a/xml/chapter5/section1/subsection5.xml
+++ b/xml/chapter5/section1/subsection5.xml
@@ -1,32 +1,53 @@
-    <SUBSECTION>
-      <NAME>
-  Instruction Summary
-      </NAME>
-
-      <LABEL NAME="sec:instruction-summary"/>
-      <INDEX>register-machine language<SUBINDEX>instructions</SUBINDEX></INDEX>
-
-      <TEXT>
-  <INDEX>register-machine language<SUBINDEX>reg@<SCHEMEINLINE>reg</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>const@<SCHEMEINLINE>const</SCHEMEINLINE></SUBINDEX></INDEX>
-  A controller instruction in our register-machine language
-  has one of the following forms, where each
-  <LATEXINLINE>$\textit{input}_i$</LATEXINLINE> is either <SPLITINLINE><SCHEME><SCHEMEINLINE>(reg ^register-name^)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>reg(</JAVASCRIPTINLINE><LATEXINLINE>$\textit{register-name}$</LATEXINLINE><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  or <SPLITINLINE><SCHEME><SCHEMEINLINE>(const ^constant-value^)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>constant(</JAVASCRIPTINLINE><LATEXINLINE>$\textit{constant-value}$</LATEXINLINE><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.
-      </TEXT>
-
-      <TEXT>
-  These instructions were introduced in
-  section<SPACE/><REF NAME="sec:register-machine-language"/>:
-  <INDEX>register-machine language<SUBINDEX>assign@<SCHEMEINLINE>assign</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>op@<SCHEMEINLINE>op</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>perform@<SCHEMEINLINE>perform</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>test@<SCHEMEINLINE>test</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>branch@<SCHEMEINLINE>branch</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>label@<SCHEMEINLINE>label</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>goto@<SCHEMEINLINE>goto</SCHEMEINLINE></SUBINDEX></INDEX>
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+<SUBSECTION>
+  <NAME>
+    Instruction Summary
+  </NAME>
+
+  <LABEL NAME="sec:instruction-summary"/>
+  <INDEX>register-machine language<SUBINDEX>instructions</SUBINDEX></INDEX>
+
+  <TEXT>
+    <INDEX>register-machine language
+    <SUBINDEX>reg@<SCHEMEINLINE>reg</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>const@<SCHEMEINLINE>const</SCHEMEINLINE></SUBINDEX></INDEX>
+    A controller instruction in our register-machine language
+    has one of the following forms, where each
+    <LATEXINLINE>$\textit{input}_i$</LATEXINLINE> is either
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>(reg ^register-name^)</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>reg(</JAVASCRIPTINLINE><LATEXINLINE>$\textit{register-name}$</LATEXINLINE><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    or
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>(const ^constant-value^)</SCHEMEINLINE>.</SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>constant(</JAVASCRIPTINLINE><LATEXINLINE>$\textit{constant-value}$</LATEXINLINE><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE>.
+      </JAVASCRIPT>
+      </SPLITINLINE>
+  </TEXT>
+
+  <TEXT>
+    These instructions were introduced in
+    section<SPACE/><REF NAME="sec:register-machine-language"/>:
+    <INDEX>register-machine language
+    <SUBINDEX>assign@<SCHEMEINLINE>assign</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>op@<SCHEMEINLINE>op</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>perform@<SCHEMEINLINE>perform</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>test@<SCHEMEINLINE>test</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>branch@<SCHEMEINLINE>branch</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>label@<SCHEMEINLINE>label</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>goto@<SCHEMEINLINE>goto</SCHEMEINLINE></SUBINDEX></INDEX>
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (assign ^register-name^ (reg ^register-name^))
 
       (assign ^register-name^ (const ^constant-value^))
@@ -40,8 +61,8 @@
       (branch (label ^label-name^))
 
       (goto (label ^label-name^))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 assign($\textit{register-name}$, reg($\textit{register-name}$))
 
 assign($\textit{register-name}$, constant($\textit{constant-value}$))
@@ -55,58 +76,87 @@ test(list(op($\textit{operation-name}$), $\textit{input}_{1}$, $\ldots$, $\texti
 branch(label($\textit{label-name}$))
 
 go_to(label($\textit{label-name}$))
-    </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  The use of registers to hold labels was introduced in
-  section<SPACE/><REF NAME="sec:subroutines"/>:
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    The use of registers to hold labels was introduced in
+    section<SPACE/><REF NAME="sec:subroutines"/>:
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (assign ^register-name^ (label ^label-name^))
 
       (goto (reg ^register-name^))
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 assign($\textit{register-name}$, label($\textit{label-name}$))
 
 go_to(reg($\textit{register-name}$))
-    </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  Instructions to use the stack were introduced in
-  section<SPACE/><REF NAME="sec:stack-recursion"/>:
-  <INDEX>register-machine language<SUBINDEX>save@<SCHEMEINLINE>save</SCHEMEINLINE></SUBINDEX></INDEX>
-  <INDEX>register-machine language<SUBINDEX>restore@<SCHEMEINLINE>restore</SCHEMEINLINE></SUBINDEX></INDEX>
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    Instructions to use the stack were introduced in
+    section<SPACE/><REF NAME="sec:stack-recursion"/>:
+    <INDEX>register-machine language
+    <SUBINDEX>save@<SCHEMEINLINE>save</SCHEMEINLINE></SUBINDEX></INDEX>
+    <INDEX>register-machine language
+    <SUBINDEX>restore@<SCHEMEINLINE>restore</SCHEMEINLINE></SUBINDEX></INDEX>
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (save ^register-name^)
 
       (restore ^register-name^)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 save($\textit{register-name}$)
 
 restore($\textit{register-name}$)
-    </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  <INDEX>register-machine language<SUBINDEX>const@<SCHEMEINLINE>const</SCHEMEINLINE></SUBINDEX></INDEX>
-  <!-- \indcodeplus{const}{(in register machine)}[syntax of]-->
-  <INDEX>constant@constant, specifying in register machine</INDEX>
-  The only kind of <LATEXINLINE>constant-value</LATEXINLINE> we have seen so far is a number,
-  but later we will use strings, symbols, and lists.
-  For example,
-  <SPLITINLINE><SCHEME><SCHEMEINLINE>(const<SPACE/>"abc")</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>constant("abc")</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is the string <SCHEMEINLINE>"abc"</SCHEMEINLINE>,
-  <SPLITINLINE><SCHEME><SCHEMEINLINE>(const<SPACE/>abc)</SCHEMEINLINE> is the symbol <SCHEMEINLINE>abc</SCHEMEINLINE>,</SCHEME></SPLITINLINE>
-  <SPLITINLINE><SCHEME><SCHEMEINLINE>(const<SPACE/>(a b c))</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>constant(list(a, b, c))</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is the list <SPLITINLINE><SCHEME><SCHEMEINLINE>(a b c)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>list(a, b, c)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>,
-  and <SPLITINLINE><SCHEME><SCHEMEINLINE>(const<SPACE/>())</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>constant(null)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is the empty list.
-  <INDEX>register machine<SUBINDEX>design of|)</SUBINDEX></INDEX>
-      </TEXT>
-
-    </SUBSECTION>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    <INDEX>register-machine language
+    <SUBINDEX>const@<SCHEMEINLINE>const</SCHEMEINLINE></SUBINDEX></INDEX>
+    <!-- \indcodeplus{const}{(in register machine)}[syntax of]-->
+    <INDEX>constant@constant, specifying in register machine</INDEX>
+    The only kind of <LATEXINLINE>constant-value</LATEXINLINE> we have seen so
+    far is a number, but later we will use strings, symbols, and lists.
+    For example,
+    <SPLITINLINE>
+      <SCHEME>
+	<SCHEMEINLINE>(const<SPACE/>abc)</SCHEMEINLINE> is the symbol
+	<SCHEMEINLINE>abc</SCHEMEINLINE>,
+      </SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>constant("abc")</JAVASCRIPTINLINE>
+	is the string <SCHEMEINLINE>"abc"</SCHEMEINLINE>,
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>
+	<SCHEMEINLINE>(const<SPACE/>(a b c))</SCHEMEINLINE>
+      </SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>constant(list(a, b, c))</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is the list
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>(a b c)</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>list(a, b, c)</JAVASCRIPTINLINE>,
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    and
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>(const<SPACE/>())</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+      <JAVASCRIPTINLINE>constant(null)</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    is the empty list.
+    <INDEX>register machine<SUBINDEX>design of|)</SUBINDEX></INDEX>
+  </TEXT>
+</SUBSECTION>
diff --git a/xml/chapter5/section2/section2.xml b/xml/chapter5/section2/section2.xml
index 8e07d1fe3..5c65dae7e 100644
--- a/xml/chapter5/section2/section2.xml
+++ b/xml/chapter5/section2/section2.xml
@@ -1,104 +1,130 @@
 <SECTION>
-    <NAME>A Register-Machine Simulator</NAME>
 
-    <SECTIONCONTENT/>
+  <NAME>A Register-Machine Simulator</NAME>
 
-    <LABEL NAME="sec:simulator"/>
-    <INDEX>register machine<SUBINDEX>simulator|(</SUBINDEX></INDEX>
-    <INDEX>register-machine simulator|(</INDEX>
+  <SECTIONCONTENT/>
 
-    <TEXT>
-      In order to gain a good understanding of the design of register
-      machines, we must test the machines we design to see if they perform
-      as expected.  One way to test a design is to hand-simulate the
-      operation of the controller, as in exercise<SPACE/><REF NAME="ex:hand-sim"/>.  But this is
-      extremely tedious for all but the simplest machines.  In this section
-      we construct a simulator for machines described in the
-      register-machine language.  The simulator is a <SPLITINLINE><SCHEME>Scheme</SCHEME><JAVASCRIPT>Source</JAVASCRIPT></SPLITINLINE> program with
-      four interface
-      <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>.  The first uses a description of a register
-      machine to construct a model of the machine (a data structure whose
-      parts correspond to the parts of the machine to be simulated), and the
-      other three allow us to simulate the machine by manipulating the
-      model:
+  <LABEL NAME="sec:simulator"/>
+  <INDEX>register machine<SUBINDEX>simulator|(</SUBINDEX></INDEX>
+  <INDEX>register-machine simulator|(</INDEX>
 
-      <UL>
-  <LI>
-    <!--  \indcode{make-machine} -->
+  <TEXT>
+    In order to gain a good understanding of the design of register machines,
+    we must test the machines we design to see if they perform as expected.
+    One way to test a design is to hand-simulate the operation of the
+    controller, as in exercise<SPACE/><REF NAME="ex:hand-sim"/>.  But this is
+    extremely tedious for all but the simplest machines.  In this section we
+    construct a simulator for machines described in the register-machine
+    language.  The simulator is a
     <SPLITINLINE>
-      <SCHEME>(make-machine register-names operations controller)</SCHEME>
-      <JAVASCRIPT>
-	<JAVASCRIPTINLINE>make_machine(</JAVASCRIPTINLINE>
-        <LATEXINLINE>$\textit{register-names}\texttt{,}$</LATEXINLINE>
-        <LATEXINLINE>$\textit{operations}\texttt{,}$</LATEXINLINE>
-        <LATEXINLINE>$\textit{controller}$</LATEXINLINE>
-	<JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
-      </JAVASCRIPT>
+      <SCHEME>Scheme</SCHEME>
+      <JAVASCRIPT>JavaScript</JAVASCRIPT>
     </SPLITINLINE>
-    <BR/>
-    <!-- {\smalltt (make-machine ^register-names^ ^operations^ ^controller^)}\\ -->
-    constructs and returns a model of the machine with the given
-    registers, operations, and controller.
-  </LI>
-  <LI>
-    <!--  \indcode{set-register-contents!} -->
+    program with
+    four interface
     <SPLITINLINE>
-      <SCHEME>(set_register_contents machine-model register-name value)</SCHEME>
-      <JAVASCRIPT>
-	<JAVASCRIPTINLINE>set_register_contents(</JAVASCRIPTINLINE>
-        <LATEXINLINE>$\textit{machine-model}\texttt{,}$</LATEXINLINE>
-	<LATEXINLINE>$\textit{register-name}\texttt{,}$</LATEXINLINE>
-        <LATEXINLINE>$\textit{value}$</LATEXINLINE>
-	<JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
-      </JAVASCRIPT>
+      <SCHEME>procedures.</SCHEME>
+      <JAVASCRIPT>functions.</JAVASCRIPT>
     </SPLITINLINE>
-    <BR/>
-    <!-- {\smalltt (set-register-contents! ^machine-model^ ^register-name^ ^value^)}\\ -->
-    stores a value in a simulated register in the given machine.
-  </LI>
-  <LI>
-    <!--  \indcode{get-register-contents} -->
+    The first uses a description of a register
+    machine to construct a model of the machine (a data structure whose
+    parts correspond to the parts of the machine to be simulated), and the
+    other three allow us to simulate the machine by manipulating the
+    model:
+    <UL>
+      <LI>
+	<!--  \indcode{make-machine} -->
+	<SPLITINLINE>
+	  <SCHEME>(make-machine register-names operations controller)</SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>make_machine(</JAVASCRIPTINLINE>
+            <LATEXINLINE>$\textit{register-names}\texttt{,}$</LATEXINLINE>
+            <LATEXINLINE>$\textit{operations}\texttt{,}$</LATEXINLINE>
+            <LATEXINLINE>$\textit{controller}$</LATEXINLINE>
+	    <JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	<BR/>
+	constructs and returns a model of the machine with the given
+	registers, operations, and controller.
+      </LI>
+      <LI>
+	<!--  \indcode{set-register-contents!} -->
+	<SPLITINLINE>
+	  <SCHEME>(set_register_contents machine-model register-name value)</SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>set_register_contents(</JAVASCRIPTINLINE>
+            <LATEXINLINE>$\textit{machine-model}\texttt{,}$</LATEXINLINE>
+	    <LATEXINLINE>$\textit{register-name}\texttt{,}$</LATEXINLINE>
+            <LATEXINLINE>$\textit{value}$</LATEXINLINE>
+	    <JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	<BR/>
+	stores a value in a simulated register in the given machine.
+      </LI>
+      <LI>
+	<!--  \indcode{get-register-contents} -->
+	<SPLITINLINE>
+	  <SCHEME>(get-register-contents machine-model, register-name)</SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>get_register_contents(</JAVASCRIPTINLINE>
+            <LATEXINLINE>$\textit{machine-model}\texttt{,}$</LATEXINLINE>
+            <LATEXINLINE>$\textit{register-name}$</LATEXINLINE>
+	    <JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	<BR/>
+	returns the contents of a simulated register in the given machine.
+      </LI>
+      <LI>
+	<!-- \indcodeplus{start}{register machine}-->
+	<SPLITINLINE>
+	  <SCHEME>(start machine-model)</SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>start(</JAVASCRIPTINLINE>
+	    <LATEXINLINE>$\textit{machine-model}$</LATEXINLINE>
+	    <JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	<BR/>
+	simulates the execution of the given machine, starting from the
+	beginning of the controller sequence and stopping when it reaches the
+	end of the sequence.
+      </LI>
+    </UL>
+  </TEXT>
+
+  <TEXT>
+    As an example of how these
     <SPLITINLINE>
-      <SCHEME>(get-register-contents machine-model, register-name)</SCHEME>
-      <JAVASCRIPT>
-	<JAVASCRIPTINLINE>get_register_contents(</JAVASCRIPTINLINE>
-        <LATEXINLINE>$\textit{machine-model}\texttt{,}$</LATEXINLINE>
-        <LATEXINLINE>$\textit{register-name}$</LATEXINLINE>
-	<JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
-      </JAVASCRIPT>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
     </SPLITINLINE>
-    <BR/>
-    <!-- {\smalltt (get-register-contents ^machine-model^ ^register-name^)}\\ -->
-    returns the contents of a simulated register in the given machine.
-  </LI>
-  <LI>
-    <!-- \indcodeplus{start}{register machine}-->
+    are used, we can define
     <SPLITINLINE>
-      <SCHEME>(start machine-model)</SCHEME>
-      <JAVASCRIPT>
-	<JAVASCRIPTINLINE>start(</JAVASCRIPTINLINE>
-	<LATEXINLINE>$\textit{machine-model}$</LATEXINLINE>
-	<JAVASCRIPTINLINE>);</JAVASCRIPTINLINE>
+      <SCHEME><SCHEMEINLINE>gcd-machine</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>gcd_machine</JAVASCRIPTINLINE>
       </JAVASCRIPT>
     </SPLITINLINE>
-    <BR/>
-    <!-- {\smalltt (start ^machine-model^)}\\ -->
-    simulates the execution of the given
-    machine, starting from the beginning of the controller sequence and
-    stopping when it reaches the end of the sequence.
-  </LI>
-      </UL>
-    </TEXT>
-
-    <TEXT>
-      As an example of how these
-      <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-      are used, we can define
-      <SPLITINLINE><SCHEME>gcd-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>gcd_machine()</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to be a model of the GCD machine
-      of section<SPACE/><REF NAME="sec:register-machine-language"/> as follows:
-
-      <SNIPPET>
-  <SCHEME>
+    to be a model of the GCD machine
+    of section<SPACE/><REF NAME="sec:register-machine-language"/> as follows:
+    <SNIPPET HIDE="yes">
+      <NAME>gcd_machine_example</NAME>
+      <REQUIRES>gcd_machine</REQUIRES>
+      <REQUIRES>start</REQUIRES>
+      <JAVASCRIPT>
+set_register_contents(gcd_machine, "a", 206);
+set_register_contents(gcd_machine, "b", 40);
+start(gcd_machine);
+get_register_contents(gcd_machine, "a");	  
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>gcd_machine</NAME>
+      <REQUIRES>make_machine</REQUIRES>
+      <EXAMPLE>gcd_machine_example</EXAMPLE>
+      <SCHEME>
     <!--  \indcode{gcd}[register machine for] -->
     (define gcd-machine
     (make-machine
@@ -112,113 +138,143 @@
     (assign b (reg t))
     (goto (label test-b))
     gcd-done)))
-  </SCHEME>
-  <JAVASCRIPT>
-function gcd_machine() {
-    return make_machine(list("a", "b", "t"),
-                        list(list("rem", binary_function((a, b) => a % b)),
-                             list("=", binary_function((a, b) => a === b))),
-                        list("test-b",
-                             test(op("="), reg("b"), constant(0)),
-                             branch(label("gcd-done")),
-                             assign("t", list(op("rem"), reg("a"), reg("b"))),
-                             assign("a", list(reg("b"))),
-                             assign("b", list(reg("t"))),
-                             go_to(label("test-b")),
-                             "gcd-done"));
-}        
-  </JAVASCRIPT>
-      </SNIPPET>
-      The first argument to <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is a list of register names.
-      The next argument is a table (a list of two-element lists) that pairs
-      each operation name with a Scheme
-      <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-      that implements the operation
-      (that is, produces the same output value given the same input values).
-      The last argument specifies the controller as a list of labels and
-      machine instructions, as in section<SPACE/><REF NAME="sec:designing-register-machines"/>.
-    </TEXT>
+      </SCHEME>
+      <JAVASCRIPT>
+const gcd_machine =
+    make_machine(
+        list("a", "b", "t"),
+        list(list("rem", (a, b) => a % b),
+             list("=", (a, b) => a === b)),
+        list("test-b",
+             test(op("="), reg("b"), constant(0)),
+             branch(label("gcd-done")),
+             assign("t", list(op("rem"), reg("a"), reg("b"))),
+             assign("a", list(reg("b"))),
+             assign("b", list(reg("t"))),
+             go_to(label("test-b")),
+             "gcd-done"));
+      </JAVASCRIPT>
+    </SNIPPET>
+    The first argument to
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-machine</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is a list of register names. The next argument is a table (a list of
+    two-element lists) that pairs each operation name with a Scheme
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    that implements the operation (that is, produces the same output value
+    given the same input values). The last argument specifies the controller
+    as a list of labels and machine instructions, as in
+    section<SPACE/><REF NAME="sec:designing-register-machines"/>.
+  </TEXT>
 
-    <TEXT>
-      To compute GCDs with this machine, we set the
-      input registers, start the machine, and examine the result when the
-      simulation terminates:
-      <SNIPPET>
-  <SCHEME>
-    (set-register-contents! gcd-machine 'a 206)
-  </SCHEME>
-  <SCHEMEOUTPUT>
-    done
-  </SCHEMEOUTPUT>
-  <JAVASCRIPT>
-set_register_contents(gcd_machine, "a", 206); 
+  <TEXT>
+    To compute GCDs with this machine, we set the input registers, start the
+    machine, and examine the result when the simulation terminates:
+    <SNIPPET>
+      <NAME>set_register_contents_a</NAME>
+      <REQUIRES>gcd_machine</REQUIRES>
+      <REQUIRES>start</REQUIRES>
+      <SCHEME>
+	  (set-register-contents! gcd-machine 'a 206)
+      </SCHEME>
+      <SCHEMEOUTPUT>
+	  done
+      </SCHEMEOUTPUT>
+      <JAVASCRIPT>
+set_register_contents(gcd_machine, "a", 206);
+      </JAVASCRIPT>
+      <JAVASCRIPT_OUTPUT>
 "done"
-  </JAVASCRIPT>
-      </SNIPPET>
-
-      <SNIPPET>
-  <SCHEME>
+      </JAVASCRIPT_OUTPUT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>set_register_contents_b</NAME>
+      <REQUIRES>set_register_contents_a</REQUIRES>
+      <SCHEME>
     (set-register-contents! gcd-machine 'b 40)
-  </SCHEME>
-  <SCHEMEOUTPUT>
+      </SCHEME>
+      <SCHEMEOUTPUT>
     done
-  </SCHEMEOUTPUT>
-  <JAVASCRIPT>
+      </SCHEMEOUTPUT>
+      <JAVASCRIPT>
 set_register_contents(gcd_machine, "b", 40);
+      </JAVASCRIPT>
+      <JAVASCRIPT_OUTPUT>
 "done"
-  </JAVASCRIPT>
-      </SNIPPET>
-
-      <SNIPPET>
-  <SCHEME>
+      </JAVASCRIPT_OUTPUT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>start_gcd_machine</NAME>
+      <REQUIRES>set_register_contents_b</REQUIRES>
+      <SCHEME>
     (start gcd-machine)
-  </SCHEME>
-  <SCHEMEOUTPUT>
+      </SCHEME>
+      <SCHEMEOUTPUT>
     done
-  </SCHEMEOUTPUT>
-  <JAVASCRIPT>
+      </SCHEMEOUTPUT>
+      <JAVASCRIPT>
 start(gcd_machine);
+      </JAVASCRIPT>
+      <JAVASCRIPT_OUTPUT>
 "done"
-  </JAVASCRIPT>
-      </SNIPPET>
-
-      <SNIPPET>
-  <SCHEME>
+      </JAVASCRIPT_OUTPUT>
+    </SNIPPET>
+    <SNIPPET>
+      <NAME>get_register_contents_a</NAME>
+      <REQUIRES>start_gcd_machine</REQUIRES>
+      <SCHEME>
     (get-register-contents gcd-machine 'a)
-  </SCHEME>
-  <SCHEMEOUTPUT>
+      </SCHEME>
+      <SCHEMEOUTPUT>
     2
-  </SCHEMEOUTPUT>
-  <JAVASCRIPT>
+      </SCHEMEOUTPUT>
+      <JAVASCRIPT>
 get_register_contents(gcd_machine, "a");
+      </JAVASCRIPT>
+      <JAVASCRIPT_OUTPUT>
 2
-</JAVASCRIPT>
-      </SNIPPET>
-    </TEXT>
+      </JAVASCRIPT_OUTPUT>
+    </SNIPPET>
+  </TEXT>
 
-    <TEXT>
-      This computation will run much more slowly than a <SPLITINLINE><SCHEME>gcd</SCHEME><JAVASCRIPT>gcd</JAVASCRIPT></SPLITINLINE>
-      <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-      written in Scheme, because we will simulate low-level machine
-      instructions, such as <SPLITINLINE><SCHEME>assign</SCHEME><JAVASCRIPT>assign</JAVASCRIPT></SPLITINLINE>, by much more complex operations.
-    </TEXT>
+  <TEXT>
+    This computation will run much more slowly than a
+    <SCHEMEINLINE>gcd</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    written in
+    <SPLITINLINE>
+      <SCHEME>Scheme,</SCHEME>
+      <JAVASCRIPT>JavaScript,</JAVASCRIPT>
+    </SPLITINLINE>
+      because we will simulate low-level machine instructions, such as
+      <SCHEMEINLINE>assign</SCHEMEINLINE>, by much more complex operations.
+  </TEXT>
 
-    <EXERCISE>
-      Use the simulator to test the machines you designed in
-      exercise<SPACE/><REF NAME="ex:design-reg-machines"/>.
-      <LABEL NAME="ex:use-simulator"/>
-    </EXERCISE>
+  <EXERCISE>
+    Use the simulator to test the machines you designed in
+    exercise<SPACE/><REF NAME="ex:design-reg-machines"/>.
+    <LABEL NAME="ex:use-simulator"/>
+  </EXERCISE>
 
-    <!-- Subsection 1 : The Machine Model -->
-    &subsection5.2.1;
+  <!-- Subsection 1 : The Machine Model -->
+  &subsection5.2.1;
 
-    <!-- Subsection 2 : The Assembler -->
-    &subsection5.2.2;
+  <!-- Subsection 2 : The Assembler -->
+  &subsection5.2.2;
 
-    <!-- Subsection 3 : Generating Execution Procedures for Instructions -->
-    &subsection5.2.3;
+  <!-- Subsection 3 : Generating Execution Procedures for Instructions -->
+  &subsection5.2.3;
 
-    <!-- Subsection 4 : Monitoring Machine Performance -->
-    &subsection5.2.4;
+  <!-- Subsection 4 : Monitoring Machine Performance -->
+  &subsection5.2.4;
 
-  </SECTION>
+</SECTION>
diff --git a/xml/chapter5/section2/subsection1.xml b/xml/chapter5/section2/subsection1.xml
index 325f2a2af..c1d98ab07 100644
--- a/xml/chapter5/section2/subsection1.xml
+++ b/xml/chapter5/section2/subsection1.xml
@@ -1,38 +1,67 @@
-    <SUBSECTION>
-      <NAME>
-  The Machine Model
-      </NAME>
-
-      <LABEL NAME="sec:machine-model"/>
-
-      <TEXT>
-  The machine model generated by <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is represented as a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  with local state using the message-passing techniques
-  developed in chapter<SPACE/>3.  To build this model, <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  begins by calling the
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to construct
-  the parts of the machine model that are common to all register
-  machines.  This basic machine model constructed by <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is essentially a container for some registers and a
-  stack, together with an execution mechanism that processes the controller
-  instructions one by one.
-      </TEXT>
-
-      <TEXT>
-  <SPLITINLINE><SCHEME>Make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> then extends this basic model (by sending it
-  messages) to include the registers, operations, and controller of the
-  particular machine being defined.  First it allocates a register in
-  the new machine for each of the supplied register names and installs
-  the designated operations in the machine.  Then it uses an 
-  <INDEX>assembler</INDEX>
-  <EM>
-    assembler</EM> (described below in section<SPACE/><REF NAME="sec:assembler"/>) to
-  transform the controller list into instructions for the new machine
-  and installs these as the machine<APOS/>s instruction sequence.  <SPLITINLINE><SCHEME>Make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> returns as its value the modified machine model.
-
-  <SNIPPET>
-    <SCHEME>
+<SUBSECTION>
+  <NAME>
+    The Machine Model
+  </NAME>
+
+  <LABEL NAME="sec:machine-model"/>
+
+  <TEXT>
+    The machine model generated by <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is represented as a
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    with local state using the message-passing techniques
+    developed in chapter<SPACE/>3.  To build this model, <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
+    begins by calling the
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to construct
+    the parts of the machine model that are common to all register
+    machines.  This basic machine model constructed by <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is essentially a container for some registers and a
+    stack, together with an execution mechanism that processes the controller
+    instructions one by one.
+  </TEXT>
+
+  <TEXT>
+    <SPLITINLINE><SCHEME>Make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> then extends this basic model (by sending it
+    messages) to include the registers, operations, and controller of the
+    particular machine being defined.  First it allocates a register in
+    the new machine for each of the supplied register names and installs
+    the designated operations in the machine.  Then it uses an 
+    <INDEX>assembler</INDEX>
+    <EM>
+      assembler</EM> (described below in section<SPACE/><REF NAME="sec:assembler"/>) to
+      transform the controller list into instructions for the new machine
+      and installs these as the machine<APOS/>s instruction sequence.  <SPLITINLINE><SCHEME>Make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> returns as its value the modified machine model.
+
+
+    <SNIPPET HIDE="yes">
+      <NAME>gcd_machine_complete_example</NAME>
+      <REQUIRES>make_machine</REQUIRES>
+      <REQUIRES>start</REQUIRES>
+      <JAVASCRIPT>
+const gcd_machine =
+    make_machine(
+        list("a", "b", "t"),
+        list(list("rem", (a, b) => a % b),
+             list("=", (a, b) => a === b)),
+        list("test-b",
+             test(op("="), reg("b"), constant(0)),
+             branch(label("gcd-done")),
+             assign("t", list(op("rem"), reg("a"), reg("b"))),
+             assign("a", list(reg("b"))),
+             assign("b", list(reg("t"))),
+             go_to(label("test-b")),
+             "gcd-done"));
+set_register_contents(gcd_machine, "a", 206);
+set_register_contents(gcd_machine, "b", 40);
+start(gcd_machine);
+get_register_contents(gcd_machine, "a");	  
+      </JAVASCRIPT>
+    </SNIPPET>
+      <SNIPPET>
+	<NAME>make_machine</NAME>
+	<REQUIRES>make_new_machine</REQUIRES>
+	<REQUIRES>assemble</REQUIRES>
+	<EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+	<SCHEME>
       <!--  \indcode*{make-machine} -->
       (define (make-machine register-names ops controller-text)
       (let ((machine (make-new-machine)))
@@ -43,38 +72,40 @@
       ((machine 'install-instruction-sequence)
       (assemble controller-text machine))
       machine))
-    </SCHEME>
-  <JAVASCRIPT>
+	</SCHEME>
+	<JAVASCRIPT>
 function make_machine(register_names, ops, controller_text) {
     const machine = make_new_machine();
-
+    
     for_each(register_name => machine("allocate_register")(register_name), register_names);
     machine("install_operations")(ops);
     machine("install_instruction_sequence")(assemble(controller_text, machine));
 
     return machine;
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME>Registers</NAME>
-      </SUBHEADING>
-
-      <INDEX>register(s)<SUBINDEX>representing</SUBINDEX></INDEX>
-
-      <TEXT>
-  We will represent a register as a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  with local state, as in
-  chapter<SPACE/>3.  The
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>make-register</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_register</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> creates a register that
-  holds a value that can be accessed or changed:
-
-  <SNIPPET>
-    <SCHEME>
+	</JAVASCRIPT>
+      </SNIPPET>
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>Registers</NAME>
+  </SUBHEADING>
+
+  <INDEX>register(s)<SUBINDEX>representing</SUBINDEX></INDEX>
+
+  <TEXT>
+    We will represent a register as a
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    with local state, as in
+    chapter<SPACE/>3.  The
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>make-register</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_register</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> creates a register that
+    holds a value that can be accessed or changed:
+
+    <SNIPPET>
+      <NAME>make_register</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-register} -->
       (define (make-register name)
       (let ((contents '*unassigned*))
@@ -85,8 +116,8 @@ function make_machine(register_names, ops, controller_text) {
             (else
             (error "Unknown request - - REGISTER" message))))
       dispatch))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_register(name) {
     let contents = "*unassigned*";
 
@@ -106,17 +137,21 @@ function make_register(name) {
 
     return dispatch;
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  The following
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  are used to access registers:
-
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    The following
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    are used to access registers:
+    <SNIPPET>
+      <NAME>get_contents</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{get-contents} -->
       (define (get-contents register)
       (register 'get))
@@ -124,8 +159,8 @@ function make_register(name) {
       <!--  \indcode*{set-contents!} -->
       (define (set-contents! register value)
       ((register 'set) value))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function get_contents(register) {
     return register("get");
 }
@@ -133,28 +168,30 @@ function get_contents(register) {
 function set_contents(register, value) {
     return register("set")(value);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME>The stack</NAME>
-      </SUBHEADING>
-
-      <INDEX>stack<SUBINDEX>representing</SUBINDEX></INDEX>
-
-      <TEXT>
-  We can also represent a stack as a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  with local state.  The
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>make-stack</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_stack</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> creates a stack whose local state consists
-  of a list of the items on the stack.  A stack accepts requests to <SPLITINLINE><SCHEME>push</SCHEME><JAVASCRIPT>push</JAVASCRIPT></SPLITINLINE> an
-  item onto the stack, to <SPLITINLINE><SCHEME>pop</SCHEME><JAVASCRIPT>pop</JAVASCRIPT></SPLITINLINE> the top item off the stack
-  and return it, and to <SPLITINLINE><SCHEME>initialize</SCHEME><JAVASCRIPT>initialize</JAVASCRIPT></SPLITINLINE> the stack to empty.
-
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>The stack</NAME>
+  </SUBHEADING>
+
+  <INDEX>stack<SUBINDEX>representing</SUBINDEX></INDEX>
+
+  <TEXT>
+    We can also represent a stack as a
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    with local state.  The
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>make-stack</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_stack</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> creates a stack whose local state consists
+    of a list of the items on the stack.  A stack accepts requests to <SPLITINLINE><SCHEME>push</SCHEME><JAVASCRIPT>push</JAVASCRIPT></SPLITINLINE> an
+    item onto the stack, to <SPLITINLINE><SCHEME>pop</SCHEME><JAVASCRIPT>pop</JAVASCRIPT></SPLITINLINE> the top item off the stack
+    and return it, and to <SPLITINLINE><SCHEME>initialize</SCHEME><JAVASCRIPT>initialize</JAVASCRIPT></SPLITINLINE> the stack to empty.
+
+    <SNIPPET>
+      <NAME>make_stack</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-stack} -->
       (define (make-stack)
       (let ((s '()))
@@ -176,8 +213,8 @@ function set_contents(register, value) {
             (else (error "Unknown request - - STACK"
             message))))
       dispatch))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_stack() {
     let stack = null;
 
@@ -214,17 +251,19 @@ function make_stack() {
 
     return dispatch;
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  The following
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  are used to access stacks:
-
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    The following
+    <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
+    are used to access stacks:
+
+    <SNIPPET>
+      <NAME>pop</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{pop} -->
       (define (pop stack)
       (stack 'pop))
@@ -232,8 +271,8 @@ function make_stack() {
       <!--  \indcode*{push} -->
       (define (push stack value)
       ((stack 'push) value))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function pop(stack) {
     return stack("pop");
 }
@@ -241,78 +280,78 @@ function pop(stack) {
 function push(stack, value) {
     return stack("push")(value);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME>The basic machine</NAME>
-      </SUBHEADING>
-
-      <TEXT>
-  The <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, shown in
-  figure<SPACE/><REF NAME="fig:make-new-machine"/>, constructs an object whose local
-  state consists of a stack, an initially empty instruction sequence, a
-  list of operations that initially contains an operation to 
-  <!-- \indcodeplus{initialize-stack}{operation in register machine}-->
-  initialize
-  the stack, and a 
-  <INDEX>register table, in simulator</INDEX>
-  <EM>register table</EM> that initially contains two
-  <!-- \indcodeplus{flag}{register}-->
-  <!-- \indcodeplus{pc}{register}-->
-  registers, named <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE>
-  <INDEX>program counter</INDEX>
-  (for <QUOTE>program counter</QUOTE>).
-  The internal
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>allocate_register</SCHEME><JAVASCRIPT></JAVASCRIPT></SPLITINLINE> adds new entries to the
-  register table, and the internal
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>lookup-register</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>lookup_register</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> looks
-  up registers in the table.
-      </TEXT>
-
-      <TEXT>
-  The <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> register is used to control branching in the simulated
-  machine.  <SPLITINLINE><SCHEME>Test</SCHEME><JAVASCRIPT>Test</JAVASCRIPT></SPLITINLINE> instructions set the contents of <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> to
-  the result of the test (true or false).  <SPLITINLINE><SCHEME>Branch</SCHEME><JAVASCRIPT>Branch</JAVASCRIPT></SPLITINLINE> instructions
-  decide whether or not to branch by examining the contents of <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE>.
-      </TEXT>
-
-      <TEXT>
-  The <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> register determines the sequencing of instructions as
-  the machine runs.  This sequencing is implemented by the internal
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>execute</SCHEME><JAVASCRIPT>execute</JAVASCRIPT></SPLITINLINE>.
-  In the simulation model, each machine instruction is a data structure
-  that includes a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  of no arguments, called the 
-  <INDEX>instruction execution
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>The basic machine</NAME>
+  </SUBHEADING>
+
+  <TEXT>
+    The <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, shown in
+    figure<SPACE/><REF NAME="fig:make-new-machine"/>, constructs an object whose local
+    state consists of a stack, an initially empty instruction sequence, a
+    list of operations that initially contains an operation to 
+    <!-- \indcodeplus{initialize-stack}{operation in register machine}-->
+    initialize
+    the stack, and a 
+    <INDEX>register table, in simulator</INDEX>
+    <EM>register table</EM> that initially contains two
+    <!-- \indcodeplus{flag}{register}-->
+    <!-- \indcodeplus{pc}{register}-->
+    registers, named <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE>
+    <INDEX>program counter</INDEX>
+    (for <QUOTE>program counter</QUOTE>).
+    The internal
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>allocate_register</SCHEME><JAVASCRIPT></JAVASCRIPT></SPLITINLINE> adds new entries to the
+    register table, and the internal
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>lookup-register</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>lookup_register</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> looks
+    up registers in the table.
+  </TEXT>
+
+  <TEXT>
+    The <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> register is used to control branching in the simulated
+    machine.  <SPLITINLINE><SCHEME>Test</SCHEME><JAVASCRIPT>Test</JAVASCRIPT></SPLITINLINE> instructions set the contents of <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> to
+    the result of the test (true or false).  <SPLITINLINE><SCHEME>Branch</SCHEME><JAVASCRIPT>Branch</JAVASCRIPT></SPLITINLINE> instructions
+    decide whether or not to branch by examining the contents of <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE>.
+  </TEXT>
+
+  <TEXT>
+    The <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> register determines the sequencing of instructions as
+    the machine runs.  This sequencing is implemented by the internal
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SPLITINLINE><SCHEME>execute</SCHEME><JAVASCRIPT>execute</JAVASCRIPT></SPLITINLINE>.
+    In the simulation model, each machine instruction is a data structure
+    that includes a
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    of no arguments, called the 
+    <INDEX>instruction execution
     <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE></INDEX>
-  <INDEX>execution
+    <INDEX>execution
     <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE><SUBINDEX>in register-machine simulator</SUBINDEX></INDEX>
-  <EM>instruction
+    <EM>instruction
     execution
     <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE></EM>, such that calling this
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  simulates
-  executing the instruction.  As the simulation runs, <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> points to
-  the place in the instruction sequence beginning with the next
-  instruction to be executed.  
-  <!--  \indcode{execute} -->
-  <SPLITINLINE><SCHEME>Execute</SCHEME><JAVASCRIPT>Execute</JAVASCRIPT></SPLITINLINE> gets that instruction,
-  executes it by calling the instruction execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, and
-  repeats this cycle until there are no more instructions to execute
-  (i.e., until <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> points to the end of the instruction sequence).
-
-  <SPLIT>
-    <SCHEME>
-  <SNIPPET>
-    <SCHEME>
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    simulates
+    executing the instruction.  As the simulation runs, <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> points to
+    the place in the instruction sequence beginning with the next
+    instruction to be executed.  
+    <!--  \indcode{execute} -->
+    <SPLITINLINE><SCHEME>Execute</SCHEME><JAVASCRIPT>Execute</JAVASCRIPT></SPLITINLINE> gets that instruction,
+    executes it by calling the instruction execution
+    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, and
+    repeats this cycle until there are no more instructions to execute
+    (i.e., until <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> points to the end of the instruction sequence).
+
+    <SPLIT>
+      <SCHEME>
+	<SNIPPET EVAL="no">
+	  <SCHEME>
       <!--  \indcode*{make-new-machine} -->
       (define (make-new-machine)
       (let ((pc (make-register 'pc))
@@ -357,23 +396,33 @@ function push(stack, value) {
             ((eq? message 'operations) the-ops)
             (else (error "Unknown request - - MACHINE" message))))
       dispatch)))
-    </SCHEME>
-  </SNIPPET>
-    </SCHEME>
-    <JAVASCRIPT>
-      <FIGURE>
-  <SNIPPET>
-    <JAVASCRIPT>
+	  </SCHEME>
+	</SNIPPET>
+      </SCHEME>
+      <JAVASCRIPT>
+	<FIGURE>
+	  <SNIPPET>
+	    <NAME>make_new_machine</NAME>
+	    <REQUIRES>make_stack</REQUIRES>
+	    <REQUIRES>make_register</REQUIRES>
+	    <REQUIRES>assoc</REQUIRES>
+	    <REQUIRES>get_contents</REQUIRES>
+	    <REQUIRES>make_instruction</REQUIRES>
+	    <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+	    <JAVASCRIPT>
 function make_new_machine() {
     const pc = make_register("pc");
     const flag = make_register("flag");
     const stack = make_stack();
     let the_instruction_sequence = null;
-    let the_ops = list(list("initialize_stack", () => stack("initialize")));
+    let the_ops = list(list("initialize_stack", 
+                            () => stack("initialize")));
     let register_table = list(list("pc", pc), list("flag", flag));
+
     function allocate_register(name) {
         if (assoc(name, register_table) === undefined) {
-            register_table = pair(list(name, make_register(name)), register_table);
+            register_table = pair(list(name, make_register(name)),
+                                  register_table);
         } else {
             error(name, "Multiply defined register: ");
         }
@@ -381,6 +430,7 @@ function make_new_machine() {
     }
     function lookup_register(name) {
         const val = assoc(name, register_table);
+        
         return val === undefined
             ? error(name, "Unknown register:")
             : head(tail(val));
@@ -395,69 +445,107 @@ function make_new_machine() {
             return execute();
         }
     }
-    function dispatch(message) {
-        return message === "start"
-                ? () => { set_contents(pc, the_instruction_sequence);
-                          return execute();                          }
-            : message === "install_instruction_sequence"
-                ? seq => { the_instruction_sequence = seq; }
-            : message === "allocate_register"
-                ? allocate_register
-            : message === "get_register"
-                ? lookup_register
-            : message === "install_operations"
-                ? ops => { the_ops = append(the_ops, ops); }
-            : message === "stack"
-                ? stack
-            : message === "operations"
-                ? the_ops
-            : error(message, "Unknown request: MACHINE");
-    }
-    return dispatch;
+    return message =>
+        message === "start"
+        ? () => { set_contents(pc, the_instruction_sequence);
+                  return execute(); }
+        : message === "install_instruction_sequence"
+        ? seq => { the_instruction_sequence = seq; }
+        : message === "allocate_register"
+        ? allocate_register
+        : message === "get_register"
+        ? lookup_register
+        : message === "install_operations"
+        ? ops => { the_ops = append(the_ops, ops); }
+        : message === "stack"
+        ? stack
+        : message === "operations"
+        ? the_ops
+        : error(message, "Unknown request: machine");
 }
-    </JAVASCRIPT>
-  </SNIPPET>
-  <CAPTION>The <JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE> function,
-  which implements the basic machine model.</CAPTION>
-  <LABEL NAME="fig:make-new-machine"/>
-      </FIGURE>
-    </JAVASCRIPT>
-  </SPLIT>
-      </TEXT>
-
-      <TEXT>
-  As part of its operation, each instruction execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  modifies <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> to indicate the next instruction to be executed.
-  <SPLITINLINE><SCHEME>Branch</SCHEME><JAVASCRIPT>Branch</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>goto</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> instructions change <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> to point to
-  the new destination.  All other instructions simply advance <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE>,
-  making it point to the next instruction in the sequence.  Observe that
-  each call to <SPLITINLINE><SCHEME>execute</SCHEME><JAVASCRIPT>execute</JAVASCRIPT></SPLITINLINE> calls <SPLITINLINE><SCHEME>execute</SCHEME><JAVASCRIPT>execute</JAVASCRIPT></SPLITINLINE> again, but this does
-  not produce an infinite loop because running the instruction execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  changes the contents of <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE>.
-      </TEXT>
-
-      <TEXT>
-  <SPLITINLINE><SCHEME>Make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> returns a
-  <SPLITINLINE><SCHEME>dispatch</SCHEME><JAVASCRIPT>dispatch</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  that implements message-passing
-  access to the internal state.  Notice that starting the machine is
-  accomplished by setting <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> to the beginning of the instruction
-  sequence and calling <SPLITINLINE><SCHEME>execute</SCHEME><JAVASCRIPT>execute</JAVASCRIPT></SPLITINLINE>.
-      </TEXT>
-
-      <TEXT>
-  For convenience, we provide an alternate procedural interface to a
-  machine<APOS/>s <SPLITINLINE><SCHEME>start</SCHEME><JAVASCRIPT>start</JAVASCRIPT></SPLITINLINE> operation,
-  as well as
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  to set and examine register contents,
-  as specified at the beginning of section<SPACE/><REF NAME="sec:simulator"/>:
-
-  <SNIPPET>
-    <SCHEME>
+	    </JAVASCRIPT>
+	  </SNIPPET>
+	  <CAPTION>
+	    The <JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE> function,
+	    which implements the basic machine model.
+	  </CAPTION>
+	  <LABEL NAME="fig:make-new-machine"/>
+	</FIGURE>
+      </JAVASCRIPT>
+    </SPLIT>
+  </TEXT>
+
+  <TEXT>
+    As part of its operation, each instruction execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    modifies
+    <SCHEMEINLINE>pc</SCHEMEINLINE> to indicate the next instruction to be
+    executed.
+    <SPLITINLINE>
+      <SCHEME>
+	<SCHEMEINLINE>Branch</SCHEMEINLINE> and
+	<SCHEMEINLINE>goto</SCHEMEINLINE> instructions
+      </SCHEME>
+      <JAVASCRIPT>
+	The instructions
+	<JAVASCRIPTINLINE>branch</JAVASCRIPTINLINE>
+	and
+	<JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    change <SCHEMEINLINE>pc</SCHEMEINLINE> to point to the new destination.
+    All other instructions simply advance <SCHEMEINLINE>pc</SCHEMEINLINE>,
+    making it point to the next instruction in the sequence.  Observe that
+    each call to <SCHEMEINLINE>execute</SCHEMEINLINE> calls
+    <SCHEMEINLINE>execute</SCHEMEINLINE> again, but this does not produce an
+    infinite loop because running the instruction execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    changes the contents of <SCHEMEINLINE>pc</SCHEMEINLINE>.
+  </TEXT>
+
+  <TEXT>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Make-new-machine</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The function
+	<JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    returns a
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>dispatch</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>dispatch</JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    that implements message-passing access to the internal state.  Notice that
+    starting the machine is accomplished by setting
+    <SCHEMEINLINE>pc</SCHEMEINLINE> to the beginning of the instruction sequence
+    and calling <SCHEMEINLINE>execute</SCHEMEINLINE>.
+  </TEXT>
+
+  <TEXT>
+    For convenience, we provide an alternate procedural interface to a
+    machine<APOS/>s <SCHEMEINLINE>start</SCHEMEINLINE> operation,
+    as well as
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    to set and examine register contents, as specified at the beginning of
+    section<SPACE/><REF NAME="sec:simulator"/>:
+    <SNIPPET>
+      <NAME>start</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!-- \indcodeplus*{start}{register machine}-->
       (define (start machine)
       (machine 'start))
@@ -470,44 +558,50 @@ function make_new_machine() {
       (define (set-register-contents! machine register-name value)
       (set-contents! (get-register machine register-name) value)
       'done)
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function start(machine) {
     return machine("start")();
 }
-
 function get_register_contents(machine, register_name) {
     return get_contents(get_register(machine, register_name));
 }
-
 function set_register_contents(machine, register_name, value) {
     set_contents(get_register(machine, register_name), value);
     return "done";
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  These
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  (and many
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  in sections<SPACE/><REF NAME="sec:assembler"/>
-  and <REF NAME="sec:ex-proc"/>) use the following to look up the register with a
-  given name in a given machine:
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    These
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    (and many
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    in sections<SPACE/><REF NAME="sec:assembler"/> and <REF NAME="sec:ex-proc"/>)
+    use the following to look up the register with a given name in a given
+    machine:
+    <SNIPPET>
+      <NAME>get_register</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{get-register} -->
       (define (get-register machine reg-name)
       ((machine 'get-register) reg-name))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function get_register(machine, reg_name) {
     return machine("get_register")(reg_name);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-    </SUBSECTION>
+</SUBSECTION>
diff --git a/xml/chapter5/section2/subsection2.xml b/xml/chapter5/section2/subsection2.xml
index 179b5bd79..029fbf613 100644
--- a/xml/chapter5/section2/subsection2.xml
+++ b/xml/chapter5/section2/subsection2.xml
@@ -1,105 +1,181 @@
-    <SUBSECTION>
-      <NAME>
-  The Assembler
-      </NAME>
+<SUBSECTION>
+  <NAME>
+    The Assembler
+  </NAME>
 
-      <LABEL NAME="sec:assembler"/>
-      <INDEX>assembler|(</INDEX>
+  <LABEL NAME="sec:assembler"/>
+  <INDEX>assembler|(</INDEX>
 
-      <TEXT>
-  The assembler transforms the sequence of controller expressions for a
-  machine into a corresponding list of machine instructions, each with
-  its execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  Overall, the assembler is much like the
-  evaluators we studied in chapter<SPACE/>4<EMDASH/>there is an input language (in
-  this case, the register-machine language) and we must perform an
-  appropriate action for each type of expression in the language.
-      </TEXT>
+  <TEXT>
+    The assembler transforms the sequence of controller expressions for a
+    machine into a corresponding list of machine instructions, each with
+    its execution
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+      <JAVASCRIPT>function.</JAVASCRIPT>
+    </SPLITINLINE>
+    Overall, the assembler is much like the evaluators we studied in
+    chapter<SPACE/>4<EMDASH/>there is an input language (in this case, the
+    register-machine language) and we must perform an appropriate action for
+    each type of expression in the language.
+  </TEXT>
 
-      <TEXT>
-  <INDEX>syntactic analysis, separated from execution<SUBINDEX>in register-machine
-      simulator</SUBINDEX></INDEX>
-  The technique of producing an execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for each instruction
-  is just what we used in section<SPACE/><REF NAME="sec:separating-analysis"/> to speed
-  up the evaluator by separating analysis from runtime execution.  As we
-  saw in chapter<SPACE/>4, much useful analysis of Scheme expressions could be
-  performed without knowing the actual values of variables.  Here,
-  analogously, much useful analysis of register-machine-language
-  expressions can be performed without knowing the actual contents of
-  machine registers.  For example, we can replace references to
-  registers by pointers to the register objects, and we can
-  replace references to labels by pointers to the place in the
-  instruction sequence that the label designates.
-      </TEXT>
+  <TEXT>
+    <INDEX>syntactic analysis, separated from execution
+    <SUBINDEX>in register-machine simulator</SUBINDEX></INDEX>
+    The technique of producing an execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for each instruction is just what we used in
+    section<SPACE/><REF NAME="sec:separating-analysis"/> to speed
+    up the evaluator by separating analysis from runtime execution.  As we
+    saw in chapter<SPACE/>4, much useful analysis of Scheme expressions could
+    be performed without knowing the actual values of variables.  Here,
+    analogously, much useful analysis of register-machine-language
+    expressions can be performed without knowing the actual contents of
+    machine registers.  For example, we can replace references to
+    registers by pointers to the register objects, and we can
+    replace references to labels by pointers to the place in the
+    instruction sequence that the label designates.
+  </TEXT>
 
-      <TEXT>
-  Before it can generate the instruction execution
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>, the
-  assembler must know what all the labels refer to, so it begins by
-  scanning the controller text to separate the labels from the
-  instructions.  As it scans the text, it constructs both a list of
-  instructions and a table that associates each label with a pointer
-  into that list.  Then the assembler augments the instruction list by
-  inserting the execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for each instruction.
-      </TEXT>
+  <TEXT>
+    Before it can generate the instruction execution
+    <SPLITINLINE>
+      <SCHEME>procedures,</SCHEME>
+    <JAVASCRIPT>functions,</JAVASCRIPT></SPLITINLINE>
+    the assembler must know what all the labels refer to, so it begins by
+    scanning the controller text to separate the labels from the
+    instructions.  As it scans the text, it constructs both a list of
+    instructions and a table that associates each label with a pointer
+    into that list.  Then the assembler augments the instruction list by
+    inserting the execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for each instruction.
+  </TEXT>
 
-      <TEXT>
-  The <SPLITINLINE><SCHEME>assemble</SCHEME><JAVASCRIPT>assemble</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  is the main entry to the assembler.
-  It takes the controller text and the machine model as arguments and
-  returns the instruction sequence to be stored in the model.
-  <SPLITINLINE><SCHEME>Assemble</SCHEME><JAVASCRIPT>Assemble</JAVASCRIPT></SPLITINLINE> calls
-  <SPLITINLINE><SCHEME>extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to build the initial instruction list
-  and label table from the supplied controller text.  The second argument
-  to <SPLITINLINE><SCHEME>extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  to be called to process these results:
-  This
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  uses <SPLITINLINE><SCHEME>update-insts!</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>update_insts</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to generate the instruction execution
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  and insert them into the instruction list,
-  and returns the modified list.
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    The <SCHEMEINLINE>assemble</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is the main entry to the assembler. It takes the controller text and the
+    machine model as arguments and returns the instruction sequence to be stored
+    in the model.
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Assemble</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The function
+	<JAVASCRIPTINLINE>Assemble</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    calls
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to build the initial instruction list and label table from the supplied
+    controller text.  The second argument
+    to
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is a
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    to be called to process these results: This
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    uses
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>update-insts!</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>update_insts</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to generate the instruction execution
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    and insert them into the instruction list, and returns the modified list.
+    <SNIPPET>
+      <NAME>assemble</NAME>
+      <REQUIRES>update_insts</REQUIRES>
+      <REQUIRES>extract_labels</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{assemble} -->
       (define (assemble controller-text machine)
       (extract-labels controller-text
       (lambda (insts labels)
       (update-insts! insts labels machine)
       insts)))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function assemble(controller_text, machine) {
-    function receive(insts, labels) {
-        update_insts(insts, labels, machine);
-        return insts;
-    }
-    
-    return extract_labels(controller_text, receive);
+return extract_labels(
+           controller_text,
+           (insts, labels) => {
+               update_insts(insts, labels, machine);
+               return insts;
+           });
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  <SPLITINLINE><SCHEME>Extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  takes as arguments a list <SPLITINLINE><SCHEME>text</SCHEME><JAVASCRIPT>text</JAVASCRIPT></SPLITINLINE> (the sequence of controller
-  instruction expressions) and a <SPLITINLINE><SCHEME>receive</SCHEME><JAVASCRIPT>receive</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  <SPLITINLINE><SCHEME>Receive</SCHEME><JAVASCRIPT>Receive</JAVASCRIPT></SPLITINLINE>
-  will be called with two values: (1) a list <SPLITINLINE><SCHEME>insts</SCHEME><JAVASCRIPT>insts</JAVASCRIPT></SPLITINLINE> of instruction
-  data structures, each containing an instruction from <SPLITINLINE><SCHEME>text</SCHEME><JAVASCRIPT>text</JAVASCRIPT></SPLITINLINE>; and
-  (2) a table called <SPLITINLINE><SCHEME>labels</SCHEME><JAVASCRIPT>labels</JAVASCRIPT></SPLITINLINE>, which associates each label from
-  <SPLITINLINE><SCHEME>text</SCHEME><JAVASCRIPT>text</JAVASCRIPT></SPLITINLINE>
-  with the position in the list <SPLITINLINE><SCHEME>insts</SCHEME><JAVASCRIPT>insts</JAVASCRIPT></SPLITINLINE> that the label designates.
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The function
+	<JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    takes as arguments a list
+    <SCHEMEINLINE>text</SCHEMEINLINE> (the sequence of controller
+    instruction expressions) and a
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>receive</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>receive</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+      <JAVASCRIPT>function.</JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Receive</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>The function
+      <JAVASCRIPTINLINE>receive</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    will be called with two values: (1) a list
+    <SCHEMEINLINE>insts</SCHEMEINLINE> of instruction data structures, each
+    containing an instruction from <SCHEMEINLINE>text</SCHEMEINLINE>; and
+    (2) a table called <SCHEMEINLINE>labels</SCHEMEINLINE>, which associates each
+    label from <SCHEMEINLINE>text</SCHEMEINLINE> with the position in the list
+    <SCHEMEINLINE>insts</SCHEMEINLINE> that the label designates.
+    <SNIPPET>
+      <NAME>extract_labels</NAME>
+      <REQUIRES>make_label_entry</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{extract-labels} -->
       (define (extract-labels text receive)
       (if (null? text)
@@ -115,8 +191,8 @@ function assemble(controller_text, machine) {
             (receive (cons (make-instruction next-inst)
             insts)
             labels)))))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function extract_labels(text, receive) {
     function helper(insts, labels) { 
         const next_inst = head(text);
@@ -130,25 +206,48 @@ function extract_labels(text, receive) {
         ? receive(null, null)
         : extract_labels(tail(text), helper);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-      <TEXT>
-  <SPLITINLINE><SCHEME>Extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> works by sequentially scanning the elements of
-  the <SPLITINLINE><SCHEME>text</SCHEME><JAVASCRIPT>text</JAVASCRIPT></SPLITINLINE> and accumulating the
-  <SPLITINLINE><SCHEME>insts</SCHEME><JAVASCRIPT>insts</JAVASCRIPT></SPLITINLINE> and the <SPLITINLINE><SCHEME>labels</SCHEME><JAVASCRIPT>labels</JAVASCRIPT></SPLITINLINE>.
-  If an element is a symbol (and thus a label) an appropriate entry is
-  added to the <SPLITINLINE><SCHEME>labels</SCHEME><JAVASCRIPT>labels</JAVASCRIPT></SPLITINLINE> table.  Otherwise the element is accumulated
-  onto the <SPLITINLINE><SCHEME>insts</SCHEME><JAVASCRIPT>insts</JAVASCRIPT></SPLITINLINE> list.<FOOTNOTE>
-    <!-- \indcodeplus{receive}{<SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>}-->
-    Using the <SPLITINLINE><SCHEME>receive</SCHEME><JAVASCRIPT>receive</JAVASCRIPT></SPLITINLINE>
-    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-    here is a way to get <SPLITINLINE><SCHEME>extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to effectively return two values<EMDASH/><SPLITINLINE><SCHEME>labels</SCHEME><JAVASCRIPT>labels</JAVASCRIPT></SPLITINLINE> and
-    <SPLITINLINE><SCHEME>insts</SCHEME><JAVASCRIPT>insts</JAVASCRIPT></SPLITINLINE><EMDASH/>without explicitly making a compound data structure to
-    hold them.  An alternative implementation, which returns an explicit
-    pair of values, is
-    <SNIPPET>
+  <TEXT>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>The function
+      <JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    works by sequentially scanning the elements of the
+    <SCHEMEINLINE>text</SCHEMEINLINE> and accumulating the
+    <SCHEMEINLINE>insts</SCHEMEINLINE> and the
+    <SCHEMEINLINE>labels</SCHEMEINLINE>. If an element is a symbol (and thus a
+    label) an appropriate entry is added to the
+    <SCHEMEINLINE>labels</SCHEMEINLINE> table.  Otherwise the element is
+    accumulated onto the <SCHEMEINLINE>insts</SCHEMEINLINE>
+    list.<FOOTNOTE>
+    <!-- \indcodeplus{receive}{<SPLITINLINE><SCHEME>procedure</SCHEME>
+	 <JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>} -->
+    Using the
+    <SCHEMEINLINE>receive</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    here is a way to get
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to effectively return two
+    values<EMDASH/><SCHEMEINLINE>labels</SCHEMEINLINE> and
+    <SCHEMEINLINE>insts</SCHEMEINLINE><EMDASH/>without explicitly making a
+    compound data structure to hold them.  An alternative implementation, which
+    returns an explicit pair of values, is
+    <SNIPPET EVAL="no">
+      <NAME>extract_labels_alternative</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
       <SCHEME>
         <!--  \indcode*{extract-labels} -->
         (define (extract-labels text)
@@ -181,8 +280,10 @@ function extract_labels(text, receive) {
 }
   </JAVASCRIPT>
     </SNIPPET>
-    which would be called by <SPLITINLINE><SCHEME>assemble</SCHEME><JAVASCRIPT>assemble</JAVASCRIPT></SPLITINLINE> as follows:
-    <SNIPPET>
+    which would be called by <SCHEMEINLINE>assemble</SCHEMEINLINE> as follows:
+    <SNIPPET EVAL="no">
+      <NAME>assemble_alternative</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
       <SCHEME>
         <!--  \indcode*{assemble} -->
         (define (assemble controller-text machine)
@@ -205,25 +306,43 @@ function assemble_alternative(controller_text, machine) {
     </SNIPPET>
 
     <INDEX>returning multiple values</INDEX>
-    <INDEX><SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE><SUBINDEX>returning multiple values</SUBINDEX></INDEX>
+    <INDEX><SPLITINLINE><SCHEME>procedure</SCHEME>
+    <JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    <SUBINDEX>returning multiple values</SUBINDEX></INDEX>
     <INDEX>continuation<SUBINDEX>in register-machine simulator</SUBINDEX></INDEX>
-    You can consider our use of <SPLITINLINE><SCHEME>receive</SCHEME><JAVASCRIPT>receive</JAVASCRIPT></SPLITINLINE> as demonstrating an elegant
-    way to return multiple values, or simply an excuse to show off a
-    programming trick.  An argument like <SPLITINLINE><SCHEME>receive</SCHEME><JAVASCRIPT>receive</JAVASCRIPT></SPLITINLINE> that is the next
-    <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+    You can consider our use of <SCHEMEINLINE>receive</SCHEMEINLINE> as
+    demonstrating an elegant way to return multiple values, or simply an excuse
+    to show off a programming trick.  An argument like
+    <SCHEMEINLINE>receive</SCHEMEINLINE> that is the next
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
     to be invoked is called a <QUOTE>continuation.</QUOTE>  Recall that we
     also used continuations to implement the backtracking control
-    structure in the <SPLITINLINE><SCHEME>amb</SCHEME><JAVASCRIPT>amb</JAVASCRIPT></SPLITINLINE> evaluator in section<SPACE/><REF NAME="sec:amb-implementation"/>.</FOOTNOTE>
-      </TEXT>
-
-      <TEXT>
-  <SPLITINLINE><SCHEME>Update-insts!</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Update_insts</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> modifies the instruction list, which initially
-  contains only the text of the instructions, to include the
-  corresponding execution
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>:
+    structure in the <SCHEMEINLINE>amb</SCHEMEINLINE> evaluator in
+    section<SPACE/><REF NAME="sec:amb-implementation"/>.</FOOTNOTE>
+  </TEXT>
 
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Update-insts!</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The function
+      <JAVASCRIPTINLINE>update_insts</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    modifies the instruction list, which initially contains only the text of the
+    instructions, to include the corresponding execution
+    <SPLITINLINE>
+      <SCHEME>procedures:</SCHEME>
+      <JAVASCRIPT>functions:</JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET>
+      <NAME>update_insts</NAME>
+      <REQUIRES>get_register</REQUIRES>
+      <REQUIRES>make_execution_function</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{update-insts!} -->
       (define (update-insts! insts labels machine)
       (let ((pc (get-register machine 'pc))
@@ -238,8 +357,8 @@ function assemble_alternative(controller_text, machine) {
             (instruction-text inst) labels machine
             pc flag stack ops)))
       insts)))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function update_insts(insts, labels, machine) {
     const pc = get_register(machine, "pc");
     const flag = get_register(machine, "flag");
@@ -258,20 +377,40 @@ function update_insts(insts, labels, machine) {
                                     ops)),
                insts);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-      <TEXT>
-  The machine instruction data structure simply pairs the
-  instruction text with the corresponding execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.
-  The execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  is not yet available when <SPLITINLINE><SCHEME>extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  constructs the instruction, and is inserted later by <SPLITINLINE><SCHEME>update-insts!</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>update_insts</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    The machine instruction data structure simply pairs the
+    instruction text with the corresponding execution
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+      <JAVASCRIPT>function.</JAVASCRIPT>
+    </SPLITINLINE>
+    The execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is not yet available when
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    constructs the instruction, and is inserted later by
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>update-insts!</SCHEMEINLINE>.</SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>update_insts</JAVASCRIPTINLINE>.
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET>
+      <NAME>make_instruction</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-instruction} -->
       (define (make-instruction text)
       (cons text '()))
@@ -287,8 +426,8 @@ function update_insts(insts, labels, machine) {
       <!--  \indcode*{set-instruction-execution-proc!} -->
       (define (set-instruction-execution-proc! inst proc)
       (set-cdr! inst proc))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_instruction(text) {
     return pair(text, null);
 }
@@ -304,40 +443,45 @@ function instruction_execution_proc(inst) {
 function set_instruction_execution_proc(inst, proc) {
     set_tail(inst, proc); 
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-      <TEXT>
-  The instruction text is not used by our simulator, but it is handy to keep
-  around for debugging (see exercise<SPACE/><REF NAME="ex:reg-machine-instruction-trace"/>).
-      </TEXT>
+  <TEXT>
+    The instruction text is not used by our simulator, but it is handy to keep
+    around for debugging (see
+    exercise<SPACE/><REF NAME="ex:reg-machine-instruction-trace"/>).
+  </TEXT>
 
-      <TEXT>
-  Elements of the label table are pairs:
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    Elements of the label table are pairs:
+    <SNIPPET>
+      <NAME>make_label_entry</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-label-entry} -->
       (define (make-label-entry label-name insts)
       (cons label-name insts))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_label_entry(label_name, insts) {
     return pair(label_name, insts);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-  Entries will be looked up in the table with
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    Entries will be looked up in the table with
+    <SNIPPET>
+      <NAME>lookup_label</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{lookup-label} -->
       (define (lookup-label labels label-name)
       (let ((val (assoc label-name labels)))
       (if val
             (cdr val)
             (error "Undefined label - - ASSEMBLE" label-name))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function lookup_label(labels, label_name) {
     const val = assoc(label_name, labels);
 
@@ -345,15 +489,15 @@ function lookup_label(labels, label_name) {
         ? error(label_name, "Undefined label: ASSEMBLE")
         : tail(val);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-      <EXERCISE>
-  The following register-machine code is ambiguous, because the label
-  <SPLITINLINE><SCHEME>here</SCHEME><JAVASCRIPT>here</JAVASCRIPT></SPLITINLINE> is defined more than once:
-  <SNIPPET>
-    <SCHEME>
+  <EXERCISE>
+    The following register-machine code is ambiguous, because the label
+    <SCHEMEINLINE>here</SCHEMEINLINE> is defined more than once:
+    <SNIPPET EVAL="no">
+      <SCHEME>
       start
       (goto (label here))
       here
@@ -363,26 +507,44 @@ function lookup_label(labels, label_name) {
       (assign a (const 4))
       (goto (label there))
       there
-    </SCHEME>
-  <JAVASCRIPT>
-    "start"
+      </SCHEME>
+      <JAVASCRIPT>
+"start",
     go_to(label(here)),
-    "here",
+"here",
     assign("a", list(const(3))),
     go_to(label(there)),
-    "here",
+"here",
     assign("a", list(const(4))),
     go_to(label(there)),
-    "there",
-  </JAVASCRIPT>
-  </SNIPPET>
+"there",
+      </JAVASCRIPT>
+    </SNIPPET>
+    With the simulator as written, what will the contents of register
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>a</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>"a"</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    be when control reaches
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>there</SCHEMEINLINE>?</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>"there"</JAVASCRIPTINLINE>?</JAVASCRIPT>
+    </SPLITINLINE>
+    Modify the
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>extract-labels</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    so that the assembler will signal an error if the same label
+    name is used to indicate two different locations.
+  </EXERCISE>
+  <INDEX>assembler|)</INDEX>
+</SUBSECTION>
 
-  With the simulator as written, what will the contents of register <SPLITINLINE><SCHEME>a</SCHEME><JAVASCRIPT>a</JAVASCRIPT></SPLITINLINE>
-  be when control reaches <SPLITINLINE><SCHEME>there</SCHEME><JAVASCRIPT>there</JAVASCRIPT></SPLITINLINE>?  Modify the <SPLITINLINE><SCHEME>extract-labels</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>extract_labels</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  so that the assembler will signal an error if the same label
-  name is used to indicate two different locations.
-      </EXERCISE>
-      <INDEX>assembler|)</INDEX>
 
-    </SUBSECTION>
diff --git a/xml/chapter5/section2/subsection3.xml b/xml/chapter5/section2/subsection3.xml
index 392d62aea..9ec398d6d 100644
--- a/xml/chapter5/section2/subsection3.xml
+++ b/xml/chapter5/section2/subsection3.xml
@@ -1,27 +1,55 @@
-    <SUBSECTION>
-      <NAME>
-  Generating Execution
-  <SPLITINLINE><SCHEME>Procedures</SCHEME><JAVASCRIPT>Functions</JAVASCRIPT></SPLITINLINE>
-  for Instructions
-      </NAME>
-
-      <LABEL NAME="sec:ex-proc"/>
-      <INDEX>execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE><SUBINDEX>in register-machine simulator|(</SUBINDEX></INDEX>
-
-      <TEXT>
-  The assembler calls <SPLITINLINE><SCHEME>make-execution-procedure</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_execution_function</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to
-  generate the execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for an instruction.
-  Like the <SPLITINLINE><SCHEME>analyze</SCHEME><JAVASCRIPT>analyze</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  in the evaluator of
-  section<SPACE/><REF NAME="sec:separating-analysis"/>, this dispatches on the type of
-  instruction to generate the appropriate execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.
-  <SNIPPET>
-    <SCHEME>
+<SUBSECTION>
+  <NAME>
+    Generating Execution
+    <SPLITINLINE>
+      <SCHEME>Procedures</SCHEME>
+      <JAVASCRIPT>Functions</JAVASCRIPT>
+    </SPLITINLINE>
+    for Instructions
+  </NAME>
+
+  <LABEL NAME="sec:ex-proc"/>
+  <INDEX>execution
+  <SPLITINLINE><SCHEME>procedure</SCHEME>
+  <JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+  <SUBINDEX>in register-machine simulator|(</SUBINDEX></INDEX>
+
+  <TEXT>
+    The assembler calls
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-execution-procedure</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>make_execution_function</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to generate the execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for an instruction.
+    Like the <SCHEMEINLINE>analyze</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    in the evaluator of section<SPACE/><REF NAME="sec:separating-analysis"/>,
+    this dispatches on the type of instruction to generate the appropriate
+    execution
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+      <JAVASCRIPT>function.</JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET>
+      <NAME>make_execution_function</NAME>
+      <REQUIRES>make_assign</REQUIRES>
+      <REQUIRES>make_test</REQUIRES>
+      <REQUIRES>make_branch_5</REQUIRES>
+      <REQUIRES>make_go_to</REQUIRES>
+      <REQUIRES>make_save</REQUIRES>
+      <REQUIRES>make_perform</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-execution-procedure} -->
       (define (make-execution-procedure inst labels machine
             pc flag stack ops)
@@ -41,11 +69,11 @@
             (make-perform inst machine labels ops pc))
             (else (error "Unknown instruction type - - ASSEMBLE"
             inst))))
-    </SCHEME>
-  <JAVASCRIPT>
-function make_execution_function(inst, labels, machine, pc, flag, stack, ops) {
+      </SCHEME>
+      <JAVASCRIPT>
+function make_execution_function(inst, labels, machine, 
+                                 pc, flag, stack, ops) {
     const x = head(inst);
-
     return x === "assign"
         ? make_assign(inst, machine, labels, ops, pc)
         : x === "test"
@@ -53,46 +81,76 @@ function make_execution_function(inst, labels, machine, pc, flag, stack, ops) {
         : x === "branch"
         ? make_branch(inst, machine, labels, flag, pc)
         : x === "go_to"
-        ? make_goto(inst, machine, labels, pc)
+        ? make_go_to(inst, machine, labels, pc)
         : x === "save"
         ? make_save(inst, machine, stack, pc)
         : x === "restore"
         ? make_restore(inst, machine, stack, pc)
         : x === "perform"
         ? make_perform(inst, machine, labels, ops, pc)
-        : error(inst, "Unknown instruction type: ASSEMBLE");
-}
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  For each type of instruction in the register-machine language, there
-  is a generator that builds an appropriate execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  The
-  details of these
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  determine both the syntax and meaning of
-  the individual instructions in the register-machine language.
-  We use data abstraction to isolate the detailed syntax of
-  register-machine expressions from the general execution mechanism, as
-  we did for evaluators in section<SPACE/><REF NAME="sec:representing-expressions"/>,
-  by using syntax
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  to extract and classify the parts of an instruction.
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME><SPLITINLINE><SCHEME>Assign</SCHEME><JAVASCRIPT>Assign</JAVASCRIPT></SPLITINLINE> instructions</NAME>
-      </SUBHEADING>
-
-      <!-- \indcodeplus{assign}{(in register machine)}[simulating]-->
-      <TEXT>
-  The <SPLITINLINE><SCHEME>make-assign</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  handles <SPLITINLINE><SCHEME>assign</SCHEME><JAVASCRIPT>assign</JAVASCRIPT></SPLITINLINE> instructions:
-  <SNIPPET>
-    <SCHEME>
+        : error(inst, "Unknown instruction type in assemble:");
+}
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    For each type of instruction in the register-machine language, there
+    is a generator that builds an appropriate execution
+    <SPLITINLINE>
+      <SCHEME>procedure.</SCHEME>
+    <JAVASCRIPT>function.</JAVASCRIPT></SPLITINLINE>
+    The details of these
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    determine both the syntax and meaning of the individual instructions in the
+    register-machine language. We use data abstraction to isolate the detailed
+    syntax of register-machine expressions from the general execution mechanism,
+    as we did for evaluators in
+    section<SPACE/><REF NAME="sec:representing-expressions"/>, by using syntax
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    to extract and classify the parts of an instruction.
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>
+      <SPLITINLINE>
+	<SCHEME><SCHEMEINLINE>Assign</SCHEMEINLINE> instructions</SCHEME>
+	<JAVASCRIPT>The instruction <JAVASCRIPTINLINE>assign</JAVASCRIPTINLINE>
+	</JAVASCRIPT>
+      </SPLITINLINE>
+    </NAME>
+  </SUBHEADING>
+
+  <!-- \indcodeplus{assign}{(in register machine)}[simulating]-->
+  <TEXT>
+    The
+    <SPLITINLINE>
+      <SCHEME>make-assign</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    handles
+    <SPLITINLINE>
+      <SCHEME>assign</SCHEME>
+      <JAVASCRIPT>assign</JAVASCRIPT>
+    </SPLITINLINE>
+    instructions:
+    <SNIPPET>
+      <NAME>make_assign</NAME>
+      <REQUIRES>assign_reg_name</REQUIRES>
+      <REQUIRES>make_operation_exp</REQUIRES>
+      <REQUIRES>assign_constructor</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-assign} -->
       (define (make-assign inst machine labels operations pc)
       (let ((target
@@ -104,33 +162,39 @@ function make_execution_function(inst, labels, machine, pc, flag, stack, ops) {
             value-exp machine labels operations)
             (make-primitive-exp
             (car value-exp) machine labels))))
-      (lambda ()                <EM>; execution procedure for <SCHEMEINLINE>assign</SCHEMEINLINE></EM>
+      (lambda ()     ; execution procedure for assign
             (set-contents! target (value-proc))
             (advance-pc pc)))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_assign(inst, machine, labels, operations, pc) {
     const target = get_register(machine, assign_reg_name(inst));
     const value_exp = assign_value_exp(inst);
-    const value_fun = is_operation_exp(value_exp)
-          ? make_operation_exp(value_exp, machine, labels, operations)
-          : make_primitive_exp(head(value_exp), machine, labels);
-
-    function perform_make_assign() {
+    const value_fun =
+        is_operation_exp(value_exp)
+        ? make_operation_exp(value_exp, machine, labels, operations)
+        : make_primitive_exp(head(value_exp), machine, labels);
+    return () => {
         set_contents(target, value_fun());
         advance_pc(pc); 
-    }
-
-    return perform_make_assign;
+    };
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-  <SPLITINLINE><SCHEME>Make-assign</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_assign</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> extracts the target register name (the
-  second element of the instruction) and the value expression
-  (the rest of the list that forms the instruction)
-  from the <SPLITINLINE><SCHEME>assign</SCHEME><JAVASCRIPT>assign</JAVASCRIPT></SPLITINLINE> instruction using the selectors
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Make-assign</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The function
+	<JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    extracts the target register name (the second element of the instruction)
+    and the value expression (the rest of the list that forms the instruction)
+    from the <SCHEMEINLINE>assign</SCHEMEINLINE> instruction using the selectors
+    <SNIPPET>
+      <NAME>assign_reg_name</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{assign-reg-name} -->
       (define (assign-reg-name assign-instruction)
       (cadr assign-instruction))
@@ -138,8 +202,8 @@ function make_assign(inst, machine, labels, operations, pc) {
       <!--  \indcode*{assign-value-exp} -->
       (define (assign-value-exp assign-instruction)
       (cddr assign-instruction))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function assign_reg_name(assign_instruction) {
     return head(tail(assign_instruction));
 }
@@ -147,81 +211,187 @@ function assign_reg_name(assign_instruction) {
 function assign_value_exp(assign_instruction) { 
     return tail(tail(assign_instruction));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  The register name is looked up with <SPLITINLINE><SCHEME>get-register</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>get_register</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to produce the
-  target register object.  The value expression is passed to <SPLITINLINE><SCHEME>make-operation-exp</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_operation_exp</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> if the value is the result of an operation, and to
-  <SPLITINLINE><SCHEME>make-primitive-exp</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_primitive_exp</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> otherwise.  These
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  (shown below)
-  parse the value expression and produce an execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for the
-  value.  This is a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  of no arguments, called 
-  <!--  \indcode{value-proc} -->
-  <SPLITINLINE><SCHEME>value-proc</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>value_fun</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>,
-  which will be evaluated during the simulation to produce the actual
-  value to be assigned to the register.  Notice that the work of looking
-  up the register name and parsing the value expression is performed
-  just once, at assembly time, not every time the instruction is
-  simulated.  This saving of work is the reason we use execution
-  <INDEX>syntactic analysis, separated from execution<SUBINDEX>in register-machine
-      simulator</SUBINDEX></INDEX>
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>, and corresponds directly to the saving in work we obtained
-  by separating program analysis from execution in the evaluator of
-  section<SPACE/><REF NAME="sec:separating-analysis"/>.
-      </TEXT>
-
-      <TEXT>
-  The result returned by <SPLITINLINE><SCHEME>make-assign</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is the execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for the <SPLITINLINE><SCHEME>assign</SCHEME><JAVASCRIPT>assign</JAVASCRIPT></SPLITINLINE> instruction.  When this
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  is
-  called (by the machine model<APOS/>s <SPLITINLINE><SCHEME>execute</SCHEME><JAVASCRIPT>execute</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>),
-  it sets the contents of the target register to the result
-  obtained by executing <SPLITINLINE><SCHEME>value-proc</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>value_fun</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.  Then it advances
-  the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> to the next instruction by running the
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    The function <JAVASCRIPTINLINE>assign</JAVASCRIPTINLINE> is the matching
+    constructor for <JAVASCRIPTINLINE>assign</JAVASCRIPTINLINE> instructions.
+    <SNIPPET>
+      <NAME>assign_constructor</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <JAVASCRIPT>
+function assign(register_name, source) {
+    const a = append(list("assign", register_name), source);
+    return a;
+}
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    The register name is looked up with
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>get-register</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>get_register</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to produce the target register object.  The value expression is passed to
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-operation-exp</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_operation_exp</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    if the value is the result of an operation, and to
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-primitive-exp</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>make_primitive_exp</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    otherwise.  These
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    (shown below) parse the value expression and produce an execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for the value.  This is a
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    of no arguments, called 
+    <!--  \indcode{value-proc} -->
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>value-proc</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT>
+      <JAVASCRIPTINLINE>value_fun</JAVASCRIPTINLINE>,</JAVASCRIPT>
+    </SPLITINLINE>
+    which will be evaluated during the simulation to produce the actual
+    value to be assigned to the register.  Notice that the work of looking
+    up the register name and parsing the value expression is performed
+    just once, at assembly time, not every time the instruction is
+    simulated.  This saving of work is the reason we use execution
+    <INDEX>syntactic analysis, separated from execution
+    <SUBINDEX>in register-machine simulator</SUBINDEX></INDEX>
+    <SPLITINLINE>
+      <SCHEME>procedures,</SCHEME>
+      <JAVASCRIPT>functions,</JAVASCRIPT>
+    </SPLITINLINE>
+    and corresponds directly to the saving in work we obtained by separating
+    program analysis from execution in the evaluator of
+    section<SPACE/><REF NAME="sec:separating-analysis"/>.
+  </TEXT>
+
+  <TEXT>
+    The result returned by
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-assign</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    is the execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for the <SCHEMEINLINE>assign</SCHEMEINLINE> instruction.  When this
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is called (by the machine model<APOS/>s <SCHEMEINLINE>execute</SCHEMEINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure),</SCHEME>
+      <JAVASCRIPT>function),</JAVASCRIPT>
+    </SPLITINLINE>
+    it sets the contents of the target register to the result obtained by
+    executing
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>value-proc</SCHEMEINLINE>.</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>value_fun</JAVASCRIPTINLINE>.</JAVASCRIPT>
+    </SPLITINLINE>
+    Then it advances the <SCHEMEINLINE>pc</SCHEMEINLINE> to the next instruction
+    by running the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET>
+      <NAME>advance_pc</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{advance-pc} -->
       (define (advance-pc pc)
       (set-contents! pc (cdr (get-contents pc))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function advance_pc(pc) {
     set_contents(pc, tail(get_contents(pc))); 
-    
-}
-  </JAVASCRIPT>
-  </SNIPPET>
-  <SPLITINLINE><SCHEME>Advance-pc</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Advance_pc</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is the normal termination for all instructions except
-  <SPLITINLINE><SCHEME>branch</SCHEME><JAVASCRIPT>branch</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>goto</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME><SPLITINLINE><SCHEME>Test</SCHEME><JAVASCRIPT>Test</JAVASCRIPT></SPLITINLINE>, <SPLITINLINE><SCHEME>branch</SCHEME><JAVASCRIPT>branch</JAVASCRIPT></SPLITINLINE>, and <SPLITINLINE><SCHEME>goto</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> instructions</NAME>
-      </SUBHEADING>
-
-      <TEXT>
-  <!-- \indcodeplus{test}{(in register machine)}[simulating]-->
-  <SPLITINLINE><SCHEME>Make-test</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Make_test</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> handles <SPLITINLINE><SCHEME>test</SCHEME><JAVASCRIPT>test</JAVASCRIPT></SPLITINLINE> instructions in a similar way.  It
-  extracts the expression that specifies the condition to be tested and
-  generates an execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for it.  At simulation time, the
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for the condition is called, the result is assigned to the
-  <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> register, and the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> is advanced:
-  <SNIPPET>
-    <SCHEME>
+}
+      </JAVASCRIPT>
+    </SNIPPET>
+    <SPLITINLINE>
+      <SCHEME>Advance-pc</SCHEME>
+      <JAVASCRIPT>
+	The function
+	<JAVASCRIPTINLINE>advance_pc</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    is the normal termination for all instructions except
+    <SCHEMEINLINE>branch</SCHEMEINLINE> and <SCHEMEINLINE>goto</SCHEMEINLINE>.
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>
+      <SPLITINLINE>
+	<SCHEME>
+	  <SCHEMEINLINE>Test</SCHEMEINLINE>,
+	  <SCHEMEINLINE>branch</SCHEMEINLINE>, and
+	  <SCHEMEINLINE>goto</SCHEMEINLINE>
+	  instructions
+	</SCHEME>
+	<JAVASCRIPT>
+	  The instructions
+	  <JAVASCRIPTINLINE>test</JAVASCRIPTINLINE>,
+	  <JAVASCRIPTINLINE>branch</JAVASCRIPTINLINE>, and
+	  <JAVASCRIPTINLINE>goto</JAVASCRIPTINLINE>
+	</JAVASCRIPT>
+      </SPLITINLINE>
+    </NAME>
+  </SUBHEADING>
+
+  <TEXT>
+    <!-- \indcodeplus{test}{(in register machine)}[simulating]-->
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>Make-test</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	The function
+	<JAVASCRIPTINLINE>make_test</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    handles <SCHEMEINLINE>test</SCHEMEINLINE> instructions in a similar way.
+    It extracts the expression that specifies the condition to be tested and
+    generates an execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for it.  At simulation time, the
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for the condition is called, the result is assigned to the
+    <SCHEMEINLINE>flag</SCHEMEINLINE> register, and the
+    <SCHEMEINLINE>pc</SCHEMEINLINE> is advanced:
+    <SNIPPET>
+      <NAME>make_test</NAME>
+      <REQUIRES>advance_pc</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-test} -->
       (define (make-test inst machine labels operations flag pc)
       (let ((condition (test-condition inst)))
@@ -237,49 +407,61 @@ function advance_pc(pc) {
       <!--  \indcode*{test-condition} -->
       (define (test-condition test-instruction)
       (cdr test-instruction))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_test(inst, machine, labels, operations, flag, pc) {
     const condition = test_condition(inst);
-
     if (is_operation_exp(condition)) {
-        const condition_fun = make_operation_exp(condition, machine, labels, operations);
-
-        function perform_make_test() {
+        const condition_fun = make_operation_exp(condition,
+                                  machine, labels, operations);
+        return () => {
             set_contents(flag, condition_fun());
             advance_pc(pc); 
-        }
-
-        return perform_make_test; 
+        };
     } else {
-        error(inst, "Bad TEST instruction: ASSEMBLE");
+        error(inst, "Bad test instruction in assemble:");
     }
 }
 
+function test(op, lhs, rhs) {
+    return list("test", op, lhs, rhs);
+}
 function test_condition(test_instruction) {
     return tail(test_instruction);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  <!-- \indcodeplus{branch}{(in register machine)}[simulating]-->
-  The execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for a <SPLITINLINE><SCHEME>branch</SCHEME><JAVASCRIPT>branch</JAVASCRIPT></SPLITINLINE> instruction checks the
-  contents of the <SPLITINLINE><SCHEME>flag</SCHEME><JAVASCRIPT>flag</JAVASCRIPT></SPLITINLINE> register and either sets the contents of
-  the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> to the branch destination (if the branch is taken) or
-  else just advances the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> (if the branch is not taken).  Notice
-  that the indicated destination in a <SPLITINLINE><SCHEME>branch</SCHEME><JAVASCRIPT>branch</JAVASCRIPT></SPLITINLINE> instruction must be a
-  label, and the <SPLITINLINE><SCHEME>make-branch</SCHEME><JAVASCRIPT>make-branch</JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  enforces this.  Notice
-  also that the label is looked up at assembly time, not each time the
-  <SPLITINLINE><SCHEME>branch</SCHEME><JAVASCRIPT>branch</JAVASCRIPT></SPLITINLINE> instruction is simulated.
-
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    <!-- \indcodeplus{branch}{(in register machine)}[simulating]-->
+    The execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for a <SCHEMEINLINE>branch</SCHEMEINLINE> instruction checks the contents of
+    the <SCHEMEINLINE>flag</SCHEMEINLINE> register and either sets the contents
+    of the <SCHEMEINLINE>pc</SCHEMEINLINE> to the branch destination (if the
+    branch is taken) or else just advances the <SCHEMEINLINE>pc</SCHEMEINLINE>
+    (if the branch is not taken).  Notice that the indicated destination in a
+    <SCHEMEINLINE>branch</SCHEMEINLINE> instruction must be a label, and the
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-branch</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_branch</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    enforces this.  Notice also that the label is looked up at assembly time,
+    not each time the <SCHEMEINLINE>branch</SCHEMEINLINE> instruction is
+    simulated.
+    <SNIPPET>
+      <NAME>make_branch_5</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-branch} -->
       (define (make-branch inst machine labels flag pc)
       (let ((dest (branch-dest inst)))
@@ -295,45 +477,50 @@ function test_condition(test_instruction) {
       <!--  \indcode*{branch-dest} -->
       (define (branch-dest branch-instruction)
       (cadr branch-instruction))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_branch(inst, machine, labels, flag, pc) {
     const dest = branch_dest(inst);
-    
     if (is_label_exp(dest)) {
         const insts = lookup_label(labels, label_exp_label(dest));
-
-        function perform_make_branch() {
-            if (get_contents(flag)) {
-                set_contents(pc, insts);
-
-            } else {
-                advance_pc(pc);
-            }
-        }
-
-        return perform_make_branch;
-
+        return () => {
+                       if (get_contents(flag)) {
+                           set_contents(pc, insts);
+                       } else {
+                           advance_pc(pc);
+                       }
+                     };
     } else {
-        error(inst, "Bad BRANCH instruction: ASSEMBLE");
+        error(inst, "Bad branch instruction in assemble:");
     }
 }
 
+function branch(label) {
+    return list("branch", label);
+}
 function branch_dest(branch_instruction) {
     return head(tail(branch_instruction));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  <!-- \indcodeplus{goto}{(in register machine)}[simulating]-->
-  A <SPLITINLINE><SCHEME>goto</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> instruction is similar to a branch, except that the
-  destination may be specified either as a label or as a register, and
-  there is no condition to check<EMDASH/>the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> is always set to the
-  new destination.
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    <!-- \indcodeplus{goto}{(in register machine)}[simulating]-->
+    A
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>goto</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    instruction is similar to a branch, except that the destination may be
+    specified either as a label or as a register, and there is no condition to
+    check<EMDASH/>the <SCHEMEINLINE>pc</SCHEMEINLINE> is always set to the
+    new destination.
+    <SNIPPET>
+      <NAME>make_go_to</NAME>
+      <REQUIRES>is_register_exp</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-goto} -->
       (define (make-goto inst machine labels pc)
       (let ((dest (goto-dest inst)))
@@ -354,40 +541,45 @@ function branch_dest(branch_instruction) {
       <!--  \indcode*{goto-dest} -->
       (define (goto-dest goto-instruction)
       (cadr goto-instruction))
-    </SCHEME>
-  <JAVASCRIPT>
-function make_goto(inst, machine, labels, pc) {
+      </SCHEME>
+      <JAVASCRIPT>
+function make_go_to(inst, machine, labels, pc) {
     const dest = goto_dest(inst);
-
     if (is_label_exp(dest)) {
         const insts = lookup_label(labels, label_exp_label(dest));
         return () => set_contents(pc, insts);
-
     } else if (is_register_exp(dest)) {
         const reg = get_register(machine, register_exp_reg(dest));
         return () => set_contents(pc, get_contents(reg));
-
     } else {
-        error(inst, "Bad GOTO instruction: ASSEMBLE");
+        error(inst, "Bad go_to instruction in assemble");
     }
 }
 
+function go_to(label) {
+    return list("go_to", label);
+}
 function goto_dest(goto_instruction) {
     return head(tail(goto_instruction));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME>Other instructions</NAME>
-      </SUBHEADING>
-
-      <TEXT>
-  The stack instructions <SPLITINLINE><SCHEME>save</SCHEME><JAVASCRIPT>save</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>restore</SCHEME><JAVASCRIPT>restore</JAVASCRIPT></SPLITINLINE> simply use the
-  stack with the designated register and advance the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE>:
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>Other instructions</NAME>
+  </SUBHEADING>
+
+  <TEXT>
+    The stack instructions
+    <SCHEMEINLINE>save</SCHEMEINLINE> and <SCHEMEINLINE>restore</SCHEMEINLINE>
+    simply use the stack with the designated register and advance the
+    <SCHEMEINLINE>pc</SCHEMEINLINE>:
+    <SNIPPET>
+      <NAME>make_save</NAME>
+      <REQUIRES>pop</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!-- \indcodeplus{save}{(in register machine)}[simulating]-->
       <!--  \indcode*{make-save} -->
       (define (make-save inst machine stack pc)
@@ -409,48 +601,61 @@ function goto_dest(goto_instruction) {
       <!--  \indcode*{stack-inst-reg-name} -->
       (define (stack-inst-reg-name stack-instruction)
       (cadr stack-instruction))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_save(inst, machine, stack, pc) {
     const reg = get_register(machine, stack_inst_reg_name(inst));
-
-    function perform_make_save() {
-        push(stack, get_contents(reg));
-        advance_pc(pc);
-    }
-
-    return perform_make_save;
+    return () => {
+                   push(stack, get_contents(reg));
+                   advance_pc(pc);
+                 };
 }
 
 function make_restore(inst, machine, stack, pc) {
     const reg = get_register(machine, stack_inst_reg_name(inst));
-
-    function perform_make_restore() {
-        set_contents(reg, pop(stack));
-        advance_pc(pc); 
-    }
-
-    return perform_make_restore;
+    return () => {
+                   set_contents(reg, pop(stack));
+                   advance_pc(pc); 
+                 };
 }
 
+function save(reg) {
+    return list("save", reg);
+}
+function restore(reg) {
+    return list("restore", reg);
+}
 function stack_inst_reg_name(stack_instruction) {
     return head(tail(stack_instruction));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  <!-- \indcodeplus{perform}{(in register machine)}[simulating]-->
-  The final instruction type, handled by <SPLITINLINE><SCHEME>make-perform</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_perform</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, generates
-  an execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for the action to be performed.  At simulation
-  time, the action
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  is executed and the <SPLITINLINE><SCHEME>pc</SCHEME><JAVASCRIPT>pc</JAVASCRIPT></SPLITINLINE> advanced.
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    <!-- \indcodeplus{perform}{(in register machine)}[simulating]-->
+    The final instruction type, handled by
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-perform</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT>
+      <JAVASCRIPTINLINE>make_perform</JAVASCRIPTINLINE>,</JAVASCRIPT>
+    </SPLITINLINE>
+    generates an execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for the action to be performed.  At simulation time, the action
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is executed and the <SCHEMEINLINE>pc</SCHEMEINLINE> advanced.
+    <SNIPPET>
+      <NAME>make_perform</NAME>
+      <REQUIRES>is_operation_exp</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-perform} -->
       (define (make-perform inst machine labels operations pc)
       (let ((action (perform-action inst)))
@@ -465,47 +670,74 @@ function stack_inst_reg_name(stack_instruction) {
 
       <!--  \indcode*{perform-action} -->
       (define (perform-action inst) (cdr inst))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_perform(inst, machine, labels, operations, pc) {
     const action = perform_action(inst);
-
     if (is_operation_exp(action)) {
-        const action_fun = make_operation_exp(action, machine, labels, operations);
-        return () => { action_fun(); advance_pc(pc); }
-
+        const action_fun = make_operation_exp(action, machine,
+                                            labels, operations);
+        return () => { 
+                       action_fun(); advance_pc(pc); 
+                     };
     } else {
-        error(inst, "Bad PERFORM instruction: ASSEMBLE");
+        error(inst, "Bad perform instruction in assemble");
     }
 }
 
 function perform_action(inst) {
     return tail(inst); 
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <SUBHEADING>
-  <NAME>Execution
-    <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <SUBHEADING>
+    <NAME>Execution
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
     for subexpressions</NAME>
-      </SUBHEADING>
-
-      <TEXT>
-  <!-- \indcodeplus{reg}{(in register machine)}[simulating]-->
-  <!-- \indcodeplus{label}{(in register machine)}[simulating]-->
-  <!-- \indcodeplus{const}{(in register machine)}[simulating]-->
-  The value of a <SPLITINLINE><SCHEME>reg</SCHEME><JAVASCRIPT>reg</JAVASCRIPT></SPLITINLINE>, <SPLITINLINE><SCHEME>label</SCHEME><JAVASCRIPT>label</JAVASCRIPT></SPLITINLINE>, or <SPLITINLINE><SCHEME>const</SCHEME><JAVASCRIPT>constant</JAVASCRIPT></SPLITINLINE> expression
-  may be needed for assignment to a register (<SPLITINLINE><SCHEME>make-assign</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>) or for input to
-  an operation (<SPLITINLINE><SCHEME>make-operation-exp</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_operation_exp</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, below).  The following
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  generates execution
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  to produce values for these expressions
-  during the simulation:
-  <SNIPPET>
-    <SCHEME>
+  </SUBHEADING>
+
+  <TEXT>
+    <!-- \indcodeplus{reg}{(in register machine)}[simulating]-->
+    <!-- \indcodeplus{label}{(in register machine)}[simulating]-->
+    <!-- \indcodeplus{const}{(in register machine)}[simulating]-->
+    The value of a <SCHEMEINLINE>reg</SCHEMEINLINE>,
+    <SCHEMEINLINE>label</SCHEMEINLINE>, or
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>const</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>constant</JAVASCRIPT>
+    </SPLITINLINE>
+    expression may be needed for assignment to a register
+    <SPLITINLINE>
+      <SCHEME>(<SCHEMEINLINE>make-assign</SCHEMEINLINE>)</SCHEME>
+      <JAVASCRIPT>(<JAVASCRIPTINLINE>make_assign</JAVASCRIPTINLINE>)</JAVASCRIPT>
+    </SPLITINLINE>
+    or for input to an operation
+    <SPLITINLINE>
+      <SCHEME>(<SCHEMEINLINE>make-operation-exp</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT>
+      (<JAVASCRIPTINLINE>make_operation_exp</JAVASCRIPTINLINE>,</JAVASCRIPT>
+    </SPLITINLINE>
+    below).  The following
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    generates execution
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    to produce values for these expressions during the simulation:
+    <SNIPPET>
+      <NAME>make_primitive_exp</NAME>
+      <REQUIRES>lookup_label</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-primitive-exp} -->
       (define (make-primitive-exp exp machine labels)
       (cond ((constant-exp? exp)
@@ -522,34 +754,39 @@ function perform_action(inst) {
             (lambda () (get-contents r))))
             (else
             (error "Unknown expression type - - ASSEMBLE" exp))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_primitive_exp(exp, machine, labels) {
     if (is_constant_exp(exp)) {
         const c = constant_exp_value(exp);
         return () => c;
-        
     } else if (is_label_exp(exp)) {
         const insts = lookup_label(labels, label_exp_label(exp));
         return () => insts;
-
     } else if (is_register_exp(exp)) {
         const r = get_register(machine, register_exp_reg(exp));
         return () => get_contents(r); 
-
     } else {
-        error(exp, "Unknown expression type: ASSEMBLE");
+        error(exp, "Unknown expression type in assemble:");
     }
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  The syntax of <SPLITINLINE><SCHEME>reg</SCHEME><JAVASCRIPT>reg</JAVASCRIPT></SPLITINLINE>, <SPLITINLINE><SCHEME>label</SCHEME><JAVASCRIPT>label</JAVASCRIPT></SPLITINLINE>, and <SPLITINLINE><SCHEME>const</SCHEME><JAVASCRIPT>constant</JAVASCRIPT></SPLITINLINE> expressions
-  is determined by
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    The syntax of
+    <SCHEMEINLINE>reg</SCHEMEINLINE>, <SCHEMEINLINE>label</SCHEMEINLINE>, and
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>const</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>constant</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    expressions is determined by
+    <SNIPPET>
+      <NAME>is_register_exp</NAME>
+      <REQUIRES>tagged_list</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{register-exp} -->
       (define (register-exp? exp) (tagged-list? exp 'reg))
 
@@ -567,49 +804,82 @@ function make_primitive_exp(exp, machine, labels) {
 
       <!--  \indcode*{label-exp-label} -->
       (define (label-exp-label exp) (cadr exp))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
+function reg(name) {
+    return list("reg", name);
+}
 function is_register_exp(exp) {
     return is_tagged_list(exp, "reg");
 }
-
 function register_exp_reg(exp) {
     return head(tail(exp));
 }
 
+function constant(value) {
+    return list("constant", value);
+}
 function is_constant_exp(exp) {
     return is_tagged_list(exp, "constant");
 }
-
 function constant_exp_value(exp) {
     return head(tail(exp));
 }
 
+function label(name) {
+    return list("label", name);
+}
 function is_label_exp(exp) {
     return is_tagged_list(exp, "label");
 }
-
 function label_exp_label(exp) {
     return head(tail(exp));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  <!--  \indcodeplus{op}{(in register machine)}[simulating]-->
-  <SPLITINLINE><SCHEME>Assign</SCHEME><JAVASCRIPT>Assign</JAVASCRIPT></SPLITINLINE>, <SPLITINLINE><SCHEME>perform</SCHEME><JAVASCRIPT>perform</JAVASCRIPT></SPLITINLINE>, and <SPLITINLINE><SCHEME>test</SCHEME><JAVASCRIPT>test</JAVASCRIPT></SPLITINLINE> instructions
-  may include the application of a machine operation (specified by
-  an <SPLITINLINE><SCHEME>op</SCHEME><JAVASCRIPT>op</JAVASCRIPT></SPLITINLINE> expression) to some operands (specified by <SPLITINLINE><SCHEME>reg</SCHEME><JAVASCRIPT>reg</JAVASCRIPT></SPLITINLINE>
-  and <SPLITINLINE><SCHEME>const</SCHEME><JAVASCRIPT>constant</JAVASCRIPT></SPLITINLINE> expressions).
-  The following
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  produces an execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for an <QUOTE>operation expression</QUOTE><EMDASH/>a list containing the operation and
-  operand expressions from the instruction:
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    <!--  \indcodeplus{op}{(in register machine)}[simulating]-->
+    <SPLITINLINE>
+      <SCHEME>
+	<SCHEMEINLINE>Assign</SCHEMEINLINE>,
+	<SCHEMEINLINE>perform</SCHEMEINLINE>, and
+	<SCHEMEINLINE>test</SCHEMEINLINE>
+	instructions
+      </SCHEME>
+      <JAVASCRIPT>
+	Instructions
+	<SCHEMEINLINE>assign</SCHEMEINLINE>,
+	<SCHEMEINLINE>perform</SCHEMEINLINE>, and
+	<SCHEMEINLINE>test</SCHEMEINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    may include the application of a machine operation (specified by
+    an <SCHEMEINLINE>op</SCHEMEINLINE> expression) to some operands (specified
+    by <SCHEMEINLINE>reg</SCHEMEINLINE> and
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>const</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>constant</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    expressions). The following
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    produces an execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for an <QUOTE>operation expression</QUOTE><EMDASH/>a list containing the
+    operation and operand expressions from the instruction:
+    <SNIPPET>
+      <NAME>make_operation_exp</NAME>
+      <REQUIRES>lookup_prim</REQUIRES>
+      <REQUIRES>make_primitive_exp</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{make-operation-exp} -->
       (define (make-operation-exp exp machine labels operations)
       (let ((op (lookup-prim (operation-exp-op exp) operations))
@@ -619,27 +889,27 @@ function label_exp_label(exp) {
             (operation-exp-operands exp))))
       (lambda ()
       (apply op (map (lambda (p) (p)) aprocs)))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_operation_exp(exp, machine, labels, operations) {
     const op = lookup_prim(operation_exp_op(exp), operations);
     const aprocs = map(e => make_primitive_exp(e, machine, labels),
                        operation_exp_operands(exp));
 
-    function perform_make_operation_exp() {
-        return op(map(p => p(), aprocs));
-    }
-    
-    return perform_make_operation_exp;
+    return () => apply_in_underlying_javascript(
+                     op, map(p => p(), aprocs));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  The syntax of operation expressions is determined by
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    The syntax of operation expressions is determined by
+    <SNIPPET>
+      <NAME>is_operation_exp</NAME>
+      <REQUIRES>tagged_list</REQUIRES>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{operation-exp} -->
       (define (operation-exp? exp)
       (and (pair? exp) (tagged-list? (car exp) 'op)))
@@ -651,10 +921,13 @@ function make_operation_exp(exp, machine, labels, operations) {
       <!--  \indcode*{operation-exp-operands} -->
       (define (operation-exp-operands operation-exp)
       (cdr operation-exp))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
+function op(name) {
+    return list("op", name);
+}
 function is_operation_exp(exp) {
-    return is_pair(exp) && is_tagged_list(head(exp), "op");
+    return is_pair(exp) &amp;&amp; is_tagged_list(head(exp), "op");
 }
 
 function operation_exp_op(operation_exp) {
@@ -664,158 +937,247 @@ function operation_exp_op(operation_exp) {
 function operation_exp_operands(operation_exp) {
     return tail(operation_exp);
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <TEXT>
-  Observe that the treatment of operation expressions is very much like
-  the treatment of
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  applications by the <SPLITINLINE><SCHEME>analyze-application</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>analyze_application</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  in the evaluator of
-  section<SPACE/><REF NAME="sec:separating-analysis"/> in that we generate an execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  for each operand.  At simulation time, we call the
-  operand
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  and apply the Scheme
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  that simulates
-  the operation to the resulting values.
-  The simulation
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  is found by looking up the operation name in
-  the operation table for the machine:
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <TEXT>
+    Observe that the treatment of operation expressions is very much like
+    the treatment of
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    applications by the
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>analyze-application</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>analyze_application</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    in the evaluator of section<SPACE/><REF NAME="sec:separating-analysis"/> in
+    that we generate an execution
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    for each operand.  At simulation time, we call the operand
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    and apply the Scheme
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    that simulates the operation to the resulting values. The simulation
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    is found by looking up the operation name in the operation table for the
+    machine:
+    <SNIPPET>
+      <NAME>lookup_prim</NAME>
+      <EXAMPLE>gcd_machine_complete_example</EXAMPLE>
+      <SCHEME>
       <!--  \indcode*{lookup-prim} -->
       (define (lookup-prim symbol operations)
       (let ((val (assoc symbol operations)))
       (if val
             (cadr val)
             (error "Unknown operation - - ASSEMBLE" symbol))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function lookup_prim(symbol, operations) {
     const val = assoc(symbol, operations);
-
     return val === undefined
-        ? error(symbol, "Unknown operation: ASSEMBLE")
+        ? error(symbol, "Unknown operation in assemble:")
         : head(tail(val));
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
-
-      <EXERCISE>
-  The treatment of machine operations above permits them to operate
-  on labels as well as on constants and the contents of registers.
-  Modify the expression-processing
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  to enforce the condition
-  that operations can be used only with registers and constants.
-      </EXERCISE>
-
-      <EXERCISE>
-  Design a new syntax for register-machine instructions and modify the
-  simulator to use your new syntax.  Can you implement your new
-  syntax without changing any part of the simulator except the
-  syntax
-  <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-  in this section?
-  <LABEL NAME="ex:reg-machine-syntax"/>
-      </EXERCISE>
-
-      <EXERCISE>
-  <!-- \indcodeplus{restore}{(in register machine)}-->
-  <!-- \indcodeplus{save}{(in register machine)}-->
-  When we introduced <SPLITINLINE><SCHEME>save</SCHEME><JAVASCRIPT>save</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>restore</SCHEME><JAVASCRIPT>restore</JAVASCRIPT></SPLITINLINE> in
-  section<SPACE/><REF NAME="sec:stack-recursion"/>, we didn<APOS/>t specify what would happen
-  if you tried to restore a register that was not the last one saved, as
-  in the sequence
-
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
+
+  <EXERCISE>
+    The treatment of machine operations above permits them to operate
+    on labels as well as on constants and the contents of registers.
+    Modify the expression-processing
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    to enforce the condition that operations can be used only with registers
+    and constants.
+  </EXERCISE>
+
+  <EXERCISE>
+    Design a new syntax for register-machine instructions and modify the
+    simulator to use your new syntax.  Can you implement your new
+    syntax without changing any part of the simulator except the
+    syntax
+    <SPLITINLINE>
+      <SCHEME>procedures</SCHEME>
+      <JAVASCRIPT>functions</JAVASCRIPT>
+    </SPLITINLINE>
+    in this section?
+    <LABEL NAME="ex:reg-machine-syntax"/>
+  </EXERCISE>
+
+  <EXERCISE>
+    <!-- \indcodeplus{restore}{(in register machine)}-->
+    <!-- \indcodeplus{save}{(in register machine)}-->
+    When we introduced <SCHEMEINLINE>save</SCHEMEINLINE> and
+    <SPLITINLINE>restore</SPLITINLINE> in
+    section<SPACE/><REF NAME="sec:stack-recursion"/>, we didn<APOS/>t specify
+    what would happen if you tried to restore a register that was not the last
+    one saved, as in the sequence
+    <SNIPPET EVAL="no">
+      <SCHEME>
       (save y)
       (save x)
       (restore y)
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 save(y);
 save(x);
 restore(y);
-  </JAVASCRIPT>
-  </SNIPPET>
-  There are several reasonable possibilities for the meaning of <SPLITINLINE><SCHEME>restore</SCHEME><JAVASCRIPT>restore</JAVASCRIPT></SPLITINLINE>:
-  <OL>
-    <LI>
-      <SPLITINLINE><SCHEME>(restore y)</SCHEME><JAVASCRIPT>restore(y)</JAVASCRIPT></SPLITINLINE> puts into <SPLITINLINE><SCHEME>y</SCHEME><JAVASCRIPT>y</JAVASCRIPT></SPLITINLINE> the last value saved on the
-      stack, regardless of what register that value came from.  This is the
-      way our simulator behaves.  Show how to take advantage of this
-      behavior to eliminate one instruction from the Fibonacci machine of
-      section<SPACE/><REF NAME="sec:stack-recursion"/> (figure<SPACE/><REF NAME="fig:fib-machine"/>).
-    </LI>
-    <LI>
-      <SPLITINLINE><SCHEME>(restore y)</SCHEME><JAVASCRIPT>restore(y)</JAVASCRIPT></SPLITINLINE> puts into <SPLITINLINE><SCHEME>y</SCHEME><JAVASCRIPT>y</JAVASCRIPT></SPLITINLINE> the last value saved on the
-      stack, but only if that value was saved from <SPLITINLINE><SCHEME>y</SCHEME><JAVASCRIPT>y</JAVASCRIPT></SPLITINLINE>; otherwise, it
-      signals an error.  Modify the simulator to behave this way.  You will
-      have to change <SPLITINLINE><SCHEME>save</SCHEME><JAVASCRIPT>save</JAVASCRIPT></SPLITINLINE> to put the register name on the stack along
-      with the value.
-    </LI>
-    <LI>
-      <SPLITINLINE><SCHEME>(restore y)</SCHEME><JAVASCRIPT>restore(y)</JAVASCRIPT></SPLITINLINE> puts into <SPLITINLINE><SCHEME>y</SCHEME><JAVASCRIPT>y</JAVASCRIPT></SPLITINLINE> the last value saved from <SPLITINLINE><SCHEME>y</SCHEME><JAVASCRIPT>y</JAVASCRIPT></SPLITINLINE> regardless of what other registers were saved after <SPLITINLINE><SCHEME>y</SCHEME><JAVASCRIPT>y</JAVASCRIPT></SPLITINLINE> and not
-      restored.  Modify the simulator to behave this way.  You will have to
-      associate a separate stack with each register.  You should make the
-      <SPLITINLINE><SCHEME>initialize-stack</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>initialize_stack</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> operation initialize all the register stacks.
-    </LI>
-  </OL>
-  <LABEL NAME="ex:stack-behavior"/>
-      </EXERCISE>
-
-      <EXERCISE>
-  The simulator can be used to help determine the data paths required
-  for implementing a machine with a given controller.  Extend
-  the assembler to store the following information in the machine model:
-  <UL>
-    <LI>a list of all instructions, with duplicates removed, sorted by
-      instruction type (<SPLITINLINE><SCHEME>assign</SCHEME><JAVASCRIPT>assign</JAVASCRIPT></SPLITINLINE>, <SPLITINLINE><SCHEME>goto</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, and so on);
-
-    </LI>
-    <LI>a list (without duplicates) of the registers used to hold entry
-      points (these are the registers referenced by <SPLITINLINE><SCHEME>goto</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-      instructions);
-
-    </LI>
-    <LI>a list (without duplicates) of the registers that are <SPLITINLINE><SCHEME>save</SCHEME><JAVASCRIPT>save</JAVASCRIPT></SPLITINLINE>d
-      or <SPLITINLINE><SCHEME>restore</SCHEME><JAVASCRIPT>restore</JAVASCRIPT></SPLITINLINE>d;
-
-    </LI>
-    <LI>for each register, a list (without duplicates) of the sources from
-      which it is assigned (for example, the sources for register <SPLITINLINE><SCHEME>val</SCHEME><JAVASCRIPT>val</JAVASCRIPT></SPLITINLINE>
-      in the factorial machine of Figure<SPACE/><REF NAME="fig:fact-machine"/> are
-      <SPLITINLINE><SCHEME>(const 1)</SCHEME><JAVASCRIPT>constant(1)</JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>((op *) (reg n) (reg val))</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>op("*", reg("n"), reg("val"))</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>).
-    </LI>
-
-  </UL>
-
-  Extend the
-  message-passing interface to the machine to provide access to this new
-  information.  To test your analyzer, define the Fibonacci machine from
-  figure<SPACE/><REF NAME="fig:fib-machine"/> and examine the lists you constructed.
-  <LABEL NAME="ex:simulated-data-paths"/>
-      </EXERCISE>
-
-      <EXERCISE>
-  Modify the simulator so that it uses the controller sequence to
-  determine what registers the machine has rather than requiring a list
-  of registers as an argument to <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT> <JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.  Instead of
-  pre-allocating the registers in <SPLITINLINE><SCHEME>make-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, you can allocate
-  them one at a time when they are first seen during assembly of the
-  instructions.
-      </EXERCISE>
-      <INDEX>execution
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE><SUBINDEX>in register-machine simulator|)</SUBINDEX></INDEX>
-
-    </SUBSECTION>
+      </JAVASCRIPT>
+    </SNIPPET>
+    There are several reasonable possibilities for the meaning of
+    <SCHEMEINLINE>restore</SCHEMEINLINE>:
+    <OL>
+      <LI>
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>(restore y)</SCHEMEINLINE></SCHEME>
+	  <JAVASCRIPT><JAVASCRIPTINLINE>restore(y)</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	puts into <SCHEMEINLINE>>y</SCHEMEINLINE> the last value saved on the
+	stack, regardless of what register that value came from.  This is the
+	way our simulator behaves.  Show how to take advantage of this
+	behavior to eliminate one instruction from the Fibonacci machine of
+	section<SPACE/><REF NAME="sec:stack-recursion"/>
+	(figure<SPACE/><REF NAME="fig:fib-machine"/>).
+      </LI>
+      <LI>
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>(restore y)</SCHEMEINLINE></SCHEME>
+	  <JAVASCRIPT><JAVASCRIPTINLINE>restore(y)</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	puts into <SCHEMEINLINE>y</SCHEMEINLINE> the last value saved on the
+	stack, but only if that value was saved from
+	<SCHEMEINLINE>y</SCHEMEINLINE>; otherwise, it signals an error.  Modify
+	the simulator to behave this way.  You will have to change
+	<SCHEMEINLINE>save</SCHEMEINLINE> to put the register name on the stack
+	along with the value.
+      </LI>
+      <LI>
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>(restore y)</SCHEMEINLINE></SCHEME>
+	  <JAVASCRIPT><JAVASCRIPTINLINE>restore(y)</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	puts into <SCHEMEINLINE>y</SCHEMEINLINE> the last value saved from
+	<SCHEMEINLINE>y</SCHEMEINLINE> regardless of what other registers were
+	saved after <SCHEMEINLINE>y</SCHEMEINLINE> and not restored.  Modify the
+	simulator to behave this way.  You will have to associate a separate
+	stack with each register.  You should make the
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>initialize-stack</SCHEMEINLINE></SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>initialize_stack</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	operation initialize all the register stacks.
+      </LI>
+    </OL>
+    <LABEL NAME="ex:stack-behavior"/>
+  </EXERCISE>
+
+  <EXERCISE>
+    The simulator can be used to help determine the data paths required
+    for implementing a machine with a given controller.  Extend
+    the assembler to store the following information in the machine model:
+    <UL>
+      <LI>
+	a list of all instructions, with duplicates removed, sorted by
+	instruction type
+	(<SCHEMEINLINE>assign</SCHEMEINLINE>,
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>goto</SCHEMEINLINE>,</SCHEME>
+	  <JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE>,</JAVASCRIPT>
+	</SPLITINLINE>
+	and so on);
+      </LI>
+      <LI>
+	a list (without duplicates) of the registers used to hold entry points
+	(these are the registers referenced by
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>goto</SCHEMEINLINE></SCHEME>
+	  <JAVASCRIPT><JAVASCRIPTINLINE>go_to</JAVASCRIPTINLINE></JAVASCRIPT>
+	</SPLITINLINE>
+	instructions);
+      </LI>
+      <LI>
+	a list (without duplicates) of the registers that are
+	<SCHEMEINLINE>save</SCHEMEINLINE>d
+	or <SCHEMEINLINE>restore</SCHEMEINLINE>d;
+      </LI>
+      <LI>
+	for each register, a list (without duplicates) of the sources from
+	which it is assigned (for example, the sources for register
+	<SCHEMEINLINE>val</SCHEMEINLINE> in the factorial machine of
+	figure<SPACE/><REF NAME="fig:fact-machine"/> are
+	<SPLITINLINE>
+	  <SCHEME><SCHEMEINLINE>(const 1)</SCHEMEINLINE></SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>constant(1)</JAVASCRIPTINLINE>
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+	and
+	<SPLITINLINE>
+	  <SCHEME>
+	    <SCHEMEINLINE>((op *) (reg n) (reg val))</SCHEMEINLINE>).
+	  </SCHEME>
+	  <JAVASCRIPT>
+	    <JAVASCRIPTINLINE>op("*", reg("n"), reg("val"))</JAVASCRIPTINLINE>).
+	  </JAVASCRIPT>
+	</SPLITINLINE>
+      </LI>
+    </UL>
+    Extend the message-passing interface to the machine to provide access to
+    this new information.  To test your analyzer, define the Fibonacci machine
+    from figure<SPACE/><REF NAME="fig:fib-machine"/> and examine the lists you
+    constructed.
+    <LABEL NAME="ex:simulated-data-paths"/>
+  </EXERCISE>
+
+  <EXERCISE>
+    Modify the simulator so that it uses the controller sequence to determine
+    what registers the machine has rather than requiring a list of registers as
+    an argument to
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-machine</SCHEMEINLINE>.</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE>.</JAVASCRIPT>
+    </SPLITINLINE>
+    Instead of pre-allocating the registers in
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-machine</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT>
+      <JAVASCRIPTINLINE>make_machine</JAVASCRIPTINLINE>,</JAVASCRIPT>
+    </SPLITINLINE>
+    you can allocate them one at a time when they are first seen during assembly
+    of the instructions.
+  </EXERCISE>
+  <INDEX>execution
+  <SPLITINLINE><SCHEME>procedure</SCHEME>
+  <JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
+  <SUBINDEX>in register-machine simulator|)</SUBINDEX></INDEX>
+</SUBSECTION>
diff --git a/xml/chapter5/section2/subsection4.xml b/xml/chapter5/section2/subsection4.xml
index 7f52c3888..0526fd487 100644
--- a/xml/chapter5/section2/subsection4.xml
+++ b/xml/chapter5/section2/subsection4.xml
@@ -1,43 +1,61 @@
-    <SUBSECTION>
-      <NAME>
-  Monitoring Machine Performance
-      </NAME>
+<SUBSECTION>
+  <NAME>
+    Monitoring Machine Performance
+  </NAME>
 
-      <LABEL NAME="sec:monitor"/>
-      <INDEX>register machine<SUBINDEX>monitoring performance|(</SUBINDEX></INDEX>
+  <LABEL NAME="sec:monitor"/>
+  <INDEX>register machine<SUBINDEX>monitoring performance|(</SUBINDEX></INDEX>
 
-      <TEXT>
-  <INDEX>simulation<SUBINDEX>monitor@for monitoring performance of register machine</SUBINDEX></INDEX>
-  Simulation is useful not only for verifying the correctness of a
-  proposed machine design but also for measuring the machine<APOS/>s
-  performance.  For example, we can install in our simulation program a
-  <QUOTE>meter</QUOTE> that measures the number of stack operations used in a
-  computation.  To do this, we modify our simulated stack to keep track
-  of the number of times registers are saved on the stack and the
-  maximum depth reached by the stack, and add a message to the stack<APOS/>s
-  interface that prints the statistics, as shown below.
-  We also add an operation to the basic machine model to print the
-  stack statistics, by initializing <SPLITINLINE><SCHEME>the-ops</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>the_ops</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> in <SPLITINLINE><SCHEME>make-new-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    <INDEX>simulation
+    <SUBINDEX>monitor@for monitoring performance of register machine</SUBINDEX>
+    </INDEX>
+    Simulation is useful not only for verifying the correctness of a
+    proposed machine design but also for measuring the machine<APOS/>s
+    performance.  For example, we can install in our simulation program a
+    <QUOTE>meter</QUOTE> that measures the number of stack operations used in a
+    computation.  To do this, we modify our simulated stack to keep track
+    of the number of times registers are saved on the stack and the
+    maximum depth reached by the stack, and add a message to the stack<APOS/>s
+    interface that prints the statistics, as shown below.
+    We also add an operation to the basic machine model to print the
+    stack statistics, by initializing
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>the-ops</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>the_ops</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    in
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-new-machine</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+      <JAVASCRIPTINLINE>make_new_machine</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    to
+    <SNIPPET EVAL="no">
+      <SCHEME>
       <!-- \indcodeplus{initialize-stack}{operation in register machine}-->
       <!-- \indcodeplus{print-stack-statistics}{operation in register machine}-->
       (list (list 'initialize-stack
             (lambda () (stack 'initialize)))
       (list 'print-stack-statistics
             (lambda () (stack 'print-statistics))))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 list(list("initialize-stack", () => stack("initialize")),
      list("print-stack-statistics", () => stack("print-statistics")));
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-      <TEXT>
-  Here is the new version of <SPLITINLINE><SCHEME>make-stack</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_stack</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>:
-  <SNIPPET>
-    <SCHEME>
+  <TEXT>
+    Here is the new version of
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-stack</SCHEMEINLINE>:</SCHEME>
+      <JAVASCRIPT>
+      <JAVASCRIPTINLINE>make_stack</JAVASCRIPTINLINE>:</JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET>
+      <SCHEME>
       <!--  \indcode*{make-stack}[with monitored stack] -->
       (define (make-stack)
       (let ((s '())
@@ -75,21 +93,19 @@ list(list("initialize-stack", () => stack("initialize")),
             (else
             (error "Unknown request - - STACK" message))))
       dispatch))
-    </SCHEME>
-  <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
 function make_stack() { 
     let s = null;
     let number_pushes = 0;
     let max_depth = 0;
     let current_depth = 0;
-
     function push(x) {
         s = pair(x, s);
         number_pushes = number_pushes + 1;
         current_depth = current_depth + 1;
         max_depth = math_max(current_depth, math_max);
     }
-
     function pop() {
         if (is_null(s)) {
             error("Empty stack: POP");
@@ -98,11 +114,9 @@ function make_stack() {
             const top = head(s);
             s = tail(s);
             current_depth = current_depth - 1;
-
             return top;
         }
     }
-
     function initialize() {
         s = null;
         number_pushes = 0;
@@ -111,13 +125,11 @@ function make_stack() {
 
         return "done";
     }
-
     function print_statistics() {
         display(accumulate((b, a) => stringify(a) + b,
-                           list("\n", "total-pushes = ", number_pushes,
-                                "\n", "maximum-depth = ", max_depth)));
+                   list("\n", "total-pushes = ", number_pushes,
+                        "\n", "maximum-depth = ", max_depth)));
     }
-
     function dispatch(message) {
         return message === "push"
             ? push
@@ -129,152 +141,208 @@ function make_stack() {
             ? print_statistics()
             : error(message, "Unknown request: STACK");
     }
-
     return dispatch;
 }
-  </JAVASCRIPT>
-  </SNIPPET>
-      </TEXT>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </TEXT>
 
-      <TEXT>
-  Exercises<SPACE/><REF NAME="ex:instruction-count"/> through<SPACE/><REF NAME="ex:breakpoints"/>
-  describe other useful monitoring and debugging features that can be
-  added to the register-machine simulator.
-      </TEXT>
-      
-      <EXERCISE>
-  <!--  \indcode{factorial}[stack usage, register machine] -->
-  Measure the number of pushes and the maximum stack depth required to
-  compute <LATEXINLINE>$n!$</LATEXINLINE> for various small values of <LATEXINLINE>$n$</LATEXINLINE> using the factorial
-  machine shown in Figure<SPACE/><REF NAME="fig:fact-machine"/>.  From your data
-  determine formulas in terms of <LATEXINLINE>$n$</LATEXINLINE> for the total number of push
-  operations and the maximum stack depth used in computing <LATEXINLINE>$n!$</LATEXINLINE> for any
-  <LATEXINLINE>$n &gt; 1$</LATEXINLINE>. Note that each of these is a linear function of <LATEXINLINE>$n$</LATEXINLINE> and is
-  thus determined by two constants.  In order to get the statistics
-  printed, you will have to augment the factorial machine with instructions to
-  initialize the stack and print the statistics.
-  You may want to also modify the
-  machine so that it repeatedly reads a value for <LATEXINLINE>$n$</LATEXINLINE>, computes the
-  factorial, and prints the result (as we did for the GCD machine in
-  figure<SPACE/><REF NAME="fig:gcd-with-io"/>), so that you will not have to repeatedly
-  invoke <SPLITINLINE><SCHEME>get-register-contents</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>get_register_contents</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, <SPLITINLINE><SCHEME>set-register-contents!</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>set_register_contents</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, and
-  <SPLITINLINE><SCHEME>start</SCHEME><JAVASCRIPT>start</JAVASCRIPT></SPLITINLINE>.
-  <LABEL NAME="ex:measure-fact"/>
-      </EXERCISE>
+  <TEXT>
+    Exercises<SPACE/><REF NAME="ex:instruction-count"/>
+    through<SPACE/><REF NAME="ex:breakpoints"/>
+    describe other useful monitoring and debugging features that can be
+    added to the register-machine simulator.
+  </TEXT>
+  
+  <EXERCISE>
+    <!--  \indcode{factorial}[stack usage, register machine] -->
+    Measure the number of pushes and the maximum stack depth required to
+    compute <LATEXINLINE>$n!$</LATEXINLINE> for various small values of
+    <LATEXINLINE>$n$</LATEXINLINE> using the factorial
+    machine shown in Figure<SPACE/><REF NAME="fig:fact-machine"/>.  From your
+    data determine formulas in terms of <LATEXINLINE>$n$</LATEXINLINE> for the
+    total number of push operations and the maximum stack depth used in
+    computing <LATEXINLINE>$n!$</LATEXINLINE> for any
+    <LATEXINLINE>$n &gt; 1$</LATEXINLINE>. Note that each of these is a linear
+    function of <LATEXINLINE>$n$</LATEXINLINE> and is thus determined by two
+    constants.  In order to get the statistics printed, you will have to augment
+    the factorial machine with instructions to initialize the stack and print
+    the statistics. You may want to also modify the machine so that it
+    repeatedly reads a value for <LATEXINLINE>$n$</LATEXINLINE>, computes the
+    factorial, and prints the result (as we did for the GCD machine in
+    figure<SPACE/><REF NAME="fig:gcd-with-io"/>), so that you will not have to
+    repeatedly invoke
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>get-register-contents</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>get_register_contents</JAVASCRIPTINLINE>,
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>set-register-contents!</SCHEMEINLINE>,</SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>set_register_contents</JAVASCRIPTINLINE>,
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    and
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>start</SCHEMEINLINE>.</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>start</JAVASCRIPTINLINE>.</JAVASCRIPT>
+      </SPLITINLINE>
+    <LABEL NAME="ex:measure-fact"/>
+  </EXERCISE>
 
-      <EXERCISE>
-  Add 
-  <INDEX>instruction counting</INDEX>
-  <EM>instruction counting</EM> to the register machine simulation.
-  That is, have the machine model keep track of the number of
-  instructions executed.  Extend the machine model<APOS/>s interface to accept
-  a new message that prints the value of the instruction count and
-  resets the count to zero.
-  <LABEL NAME="ex:instruction-count"/>
-      </EXERCISE>
+  <EXERCISE>
+    Add 
+    <INDEX>instruction counting</INDEX>
+    <EM>instruction counting</EM> to the register machine simulation.
+    That is, have the machine model keep track of the number of
+    instructions executed.  Extend the machine model<APOS/>s interface to
+    accept a new message that prints the value of the instruction count and
+    resets the count to zero.
+    <LABEL NAME="ex:instruction-count"/>
+  </EXERCISE>
 
-      <EXERCISE>
-  Augment the simulator to provide for 
-  <INDEX>instruction tracing</INDEX>
-  <INDEX>tracing<SUBINDEX>instruction execution</SUBINDEX></INDEX>
-  <EM>instruction tracing</EM>.
-  That is, before each instruction is executed, the simulator should print
-  the text of the instruction.  Make the machine model accept <SPLITINLINE><SCHEME>trace-on</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>trace_on</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and
-  <SPLITINLINE><SCHEME>trace-off</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>trace_off</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> messages to turn tracing on and off.
-  <LABEL NAME="ex:reg-machine-instruction-trace"/>
-      </EXERCISE>
+  <EXERCISE>
+    Augment the simulator to provide for 
+    <INDEX>instruction tracing</INDEX>
+    <INDEX>tracing<SUBINDEX>instruction execution</SUBINDEX></INDEX>
+    <EM>instruction tracing</EM>.
+    That is, before each instruction is executed, the simulator should print
+    the text of the instruction.  Make the machine model accept
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>trace-on</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>trace_on</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    and
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>trace-off</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>trace_off</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    messages to turn tracing on and off.
+    <LABEL NAME="ex:reg-machine-instruction-trace"/>
+  </EXERCISE>
 
-      <EXERCISE>
-  Extend the instruction tracing of
-  exercise<SPACE/><REF NAME="ex:reg-machine-instruction-trace"/> so that before
-  printing an instruction, the simulator prints any labels that
-  immediately precede that instruction in the controller sequence.  Be
-  careful to do this in a way that does not interfere with instruction
-  counting (exercise<SPACE/><REF NAME="ex:instruction-count"/>).
-  You will have to make the simulator retain the necessary label information.
-      </EXERCISE>
+  <EXERCISE>
+    Extend the instruction tracing of
+    exercise<SPACE/><REF NAME="ex:reg-machine-instruction-trace"/> so that
+    before printing an instruction, the simulator prints any labels that
+    immediately precede that instruction in the controller sequence.  Be
+    careful to do this in a way that does not interfere with instruction
+    counting (exercise<SPACE/><REF NAME="ex:instruction-count"/>).
+    You will have to make the simulator retain the necessary label information.
+  </EXERCISE>
 
-      <EXERCISE>
-  <INDEX>register(s)<SUBINDEX>tracing</SUBINDEX></INDEX>
-  <INDEX>tracing<SUBINDEX>register assignment</SUBINDEX></INDEX>
-  Modify the <SPLITINLINE><SCHEME>make-register</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_register</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  of
-  section<SPACE/><REF NAME="sec:machine-model"/> so that registers can be traced.
-  Registers should accept messages that turn tracing on and off.  When a
-  register is traced, assigning a value to the register should print the
-  name of the register, the old contents of the register, and the new
-  contents being assigned.  Extend the interface to the machine model
-  to permit you to turn tracing on and off for designated machine registers.
-      </EXERCISE>
+  <EXERCISE>
+    <INDEX>register(s)<SUBINDEX>tracing</SUBINDEX></INDEX>
+    <INDEX>tracing<SUBINDEX>register assignment</SUBINDEX></INDEX>
+    Modify the
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>make-register</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>make_register</JAVASCRIPTINLINE></JAVASCRIPT>
+    </SPLITINLINE>
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    of section<SPACE/><REF NAME="sec:machine-model"/> so that registers can be
+    traced. Registers should accept messages that turn tracing on and off.  When
+    a register is traced, assigning a value to the register should print the
+    name of the register, the old contents of the register, and the new contents
+    being assigned.  Extend the interface to the machine model to permit you to
+    turn tracing on and off for designated machine registers.
+  </EXERCISE>
 
-      <EXERCISE><LABEL NAME="ex:breakpoints"/>
-  Alyssa P. Hacker wants a 
-  <INDEX>breakpoint</INDEX>
-  <EM>breakpoint</EM> feature in the simulator to
-  help her debug her machine designs.  You have been hired to install
-  this feature for her.  She wants to be able to specify a place in the
-  controller sequence where the simulator will stop and allow her to
-  examine the state of the machine.  You are to implement a
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+  <EXERCISE>
+    <LABEL NAME="ex:breakpoints"/>
+    Alyssa P. Hacker wants a 
+    <INDEX>breakpoint</INDEX>
+    <EM>breakpoint</EM> feature in the simulator to help her debug her machine
+    designs.  You have been hired to install this feature for her.  She wants to
+    be able to specify a place in the controller sequence where the simulator
+    will stop and allow her to examine the state of the machine.  You are to
+    implement a
+    <SPLITINLINE>
+      <SCHEME>procedure</SCHEME>
+      <JAVASCRIPT>function</JAVASCRIPT>
+    </SPLITINLINE>
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (set-breakpoint $machine$ $label$ $n$)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
       set_breakpoint($machine$, $label$, $n$);
-    </JAVASCRIPT>
-  </SNIPPET>
-  that sets a breakpoint just before the <LATEXINLINE>$n$</LATEXINLINE>th instruction after the
-  given label.  For example,
-
-  <SNIPPET>
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    that sets a breakpoint just before the <LATEXINLINE>$n$</LATEXINLINE>th
+    instruction after the given label.  For example,
+    <SNIPPET>
+      <SCHEME>
       (set-breakpoint gcd-machine 'test-b 4)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
       set_breakpoint(gcd_machine, "test-b", 4);
-    </JAVASCRIPT>
-  </SNIPPET>
-  installs a breakpoint in <SPLITINLINE><SCHEME>gcd-machine</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>gcd_machine</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> just before the
-  assignment to register <SPLITINLINE><SCHEME>a</SCHEME><JAVASCRIPT>a</JAVASCRIPT></SPLITINLINE>.  When the simulator reaches the
-  breakpoint it should print the label and the offset of the breakpoint
-  and stop executing instructions.  Alyssa can then use <SPLITINLINE><SCHEME>get-register-contents</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>get_register_contents</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME>set-register-contents!</SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>set_register_contents</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to manipulate
-  the state of the simulated machine.  She should then be able to
-  continue execution by saying
-
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    installs a breakpoint in
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>gcd-machine</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>gcd_machine</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    just before the assignment to register
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>a</SCHEMEINLINE>.</SCHEME>
+      <JAVASCRIPT><JAVASCRIPTINLINE>"a"</JAVASCRIPTINLINE>.</JAVASCRIPT>
+    </SPLITINLINE>
+    When the simulator reaches the breakpoint it should print the label and the
+    offset of the breakpoint and stop executing instructions.  Alyssa can then
+    use
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>get-register-contents</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>get_register_contents</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    and
+    <SPLITINLINE>
+      <SCHEME><SCHEMEINLINE>set-register-contents!</SCHEMEINLINE></SCHEME>
+      <JAVASCRIPT>
+	<JAVASCRIPTINLINE>set_register_contents</JAVASCRIPTINLINE>
+      </JAVASCRIPT>
+    </SPLITINLINE>
+    to manipulate the state of the simulated machine.  She should then be able
+    to continue execution by saying
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (proceed-machine $machine$)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
       proceed_machine($machine$);
-    </JAVASCRIPT>
-  </SNIPPET>
-  She should also be able to remove a specific breakpoint by means of
-
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    She should also be able to remove a specific breakpoint by means of
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (cancel-breakpoint $machine$ $label$ $n$)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
       cancel_breakpoint($machine$, $label$, $n$);
-    </JAVASCRIPT>
-  </SNIPPET>
-  or to remove all breakpoints by means of
-
-  <SNIPPET EVAL="no" LATEX="yes">
-    <SCHEME>
+      </JAVASCRIPT>
+    </SNIPPET>
+    or to remove all breakpoints by means of
+    <SNIPPET EVAL="no" LATEX="yes">
+      <SCHEME>
       (cancel-all-breakpoints $machine$)
-    </SCHEME>
-    <JAVASCRIPT>
+      </SCHEME>
+      <JAVASCRIPT>
       cancel_all_breakpoints($machine$);
-    </JAVASCRIPT>
-  </SNIPPET>
-      </EXERCISE>
-      <INDEX>register machine<SUBINDEX>simulator|)</SUBINDEX></INDEX>
-      <INDEX>register-machine simulator|)</INDEX>
-      <INDEX>register machine<SUBINDEX>monitoring performance|)</SUBINDEX></INDEX>
-
-    </SUBSECTION>
+      </JAVASCRIPT>
+    </SNIPPET>
+  </EXERCISE>
+  <INDEX>register machine<SUBINDEX>simulator|)</SUBINDEX></INDEX>
+  <INDEX>register-machine simulator|)</INDEX>
+  <INDEX>register machine<SUBINDEX>monitoring performance|)</SUBINDEX></INDEX>
+</SUBSECTION>
diff --git a/xml/chapter5/section3/subsection1.xml b/xml/chapter5/section3/subsection1.xml
index eea8e08da..986ddc023 100644
--- a/xml/chapter5/section3/subsection1.xml
+++ b/xml/chapter5/section3/subsection1.xml
@@ -30,7 +30,7 @@
   To model computer memory, we use a new kind of data
   structure called a 
   <INDEX>vector (data structure)</INDEX>
-  <EM>vector</EM> <SPLITINLINE><JAVASCRIPTINLINE>(in JavaScript, a vector is essentially just a wrapper around an array)</JAVASCRIPTINLINE></SPLITINLINE>.  Abstractly, a vector is a compound
+  <EM>vector</EM> <SPLITINLINE><JAVASCRIPT>(in JavaScript, a vector is essentially just a wrapper around an array)</JAVASCRIPT></SPLITINLINE>.  Abstractly, a vector is a compound
   data object whose individual elements can be accessed by means of an
   integer index in an amount of time that is independent of the
   index.<FOOTNOTE>We could represent memory as lists of items.
@@ -48,7 +48,7 @@
         <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
         (those marked <EM>ns</EM> are not in the IEEE Scheme standard)}[vector-ref@<SCHEMEINLINE>vector-ref</SCHEMEINLINE>]
         -->
-    <LI><SPLITINLINE><SCHEME><SCHEMEINLINE>(vector-ref </SCHEMEINLINE><LATEXINLINE>vector n</LATEXINLINE><SCHEMEINLINE>)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>vector_ref(</JAVASCRIPTINLINE><LATEXINLINE>$\textit{vector}, \textit{n}$</LATEXINLINE><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> returns the <LATEXINLINE>$n$</LATEXINLINE>th
+    <LI><SPLITINLINE><SCHEME><SCHEMEINLINE>(vector-ref </SCHEMEINLINE><LATEXINLINE>vector n</LATEXINLINE><SCHEMEINLINE>)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>vector_ref(</JAVASCRIPTINLINE><EM>vector</EM>, <EM>n</EM><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> returns the <LATEXINLINE>$n$</LATEXINLINE>th
       element of the vector.
 
       <!-- \indprim*{vector-set!}-->
@@ -57,7 +57,7 @@
     (those marked <EM>ns</EM> are not in the IEEE Scheme standard)}[vector-set!@<SCHEMEINLINE>vector-set!</SCHEMEINLINE>]
     -->
     </LI>
-    <LI><SPLITINLINE><SCHEME><SCHEMEINLINE>(vector-set! </SCHEMEINLINE><LATEXINLINE>vector n value</LATEXINLINE><SCHEMEINLINE>)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>vector_set(</JAVASCRIPTINLINE><LATEXINLINE><EM>vector</EM>, <EM>n</EM>, <EM>value</EM></LATEXINLINE><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> sets
+    <LI><SPLITINLINE><SCHEME><SCHEMEINLINE>(vector-set! </SCHEMEINLINE><LATEXINLINE>vector n value</LATEXINLINE><SCHEMEINLINE>)</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>vector_set(</JAVASCRIPTINLINE><EM>vector</EM>, <EM>n</EM>, <EM>value</EM><JAVASCRIPTINLINE>)</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> sets
       the <LATEXINLINE>$n$</LATEXINLINE>th element of the vector to the designated value.
     </LI>
 
@@ -153,7 +153,7 @@
     </SCHEME>
     <JAVASCRIPT>
       <FIGURE>
-      <FIGURE src="img_javascript/Fig5.14b.std.svg"/>
+      <FIGURE scale_factor="2" src="img_javascript/Fig5.14b.std.svg"/>
         <CAPTION>Box-and-pointer and memory-vector representations 
         of the list <JAVASCRIPTINLINE>list(list(1, 2), 3, 4)</JAVASCRIPTINLINE>.</CAPTION>
         <LABEL NAME="fig:box-and-pointer-memory"/>
@@ -251,8 +251,8 @@
       (assign ^reg<LATEXINLINE>$_{1}$</LATEXINLINE>^ (op cdr) (reg ^reg<LATEXINLINE>$_{2}$</LATEXINLINE>^))
     </SCHEME>
     <JAVASCRIPT>
-assign(reg<LATEXINLINE>$_{1}$</LATEXINLINE>,list(op("head"), reg<LATEXINLINE>$_{2}$</LATEXINLINE>))
-assign(reg<LATEXINLINE>$_{1}$</LATEXINLINE>,list(op("tail"), reg<LATEXINLINE>$_{2}$</LATEXINLINE>))
+assign(reg1, list(op("head"), reg2))
+assign(reg1, list(op("tail"), reg2))
     </JAVASCRIPT>
   </SNIPPET>
 
@@ -264,8 +264,8 @@ assign(reg<LATEXINLINE>$_{1}$</LATEXINLINE>,list(op("tail"), reg<LATEXINLINE>$_{
       (assign ^reg<LATEXINLINE>$_{1}$</LATEXINLINE>^ (op vector-ref) (reg the-cdrs) (reg ^reg<LATEXINLINE>$_{2}$</LATEXINLINE>^))
     </SCHEME>
     <JAVASCRIPT>
-assign(reg<LATEXINLINE>$_{1}$</LATEXINLINE>,list(op("vector_ref"), reg("the_heads"), reg<LATEXINLINE>$_{2}$</LATEXINLINE>))
-assign(reg<LATEXINLINE>$_{1}$</LATEXINLINE>,list(op("vector_ref"), reg("the_tails"), reg<LATEXINLINE>$_{2}$</LATEXINLINE>))
+assign(reg1, list(op("vector_ref"), reg("the_heads"), reg2))
+assign(reg1, list(op("vector_ref"), reg("the_tails"), reg2))
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -280,8 +280,8 @@ assign(reg<LATEXINLINE>$_{1}$</LATEXINLINE>,list(op("vector_ref"), reg("the_tail
       (perform (op set-cdr!) (reg ^reg<LATEXINLINE>$_{1}$</LATEXINLINE>^) (reg ^reg<LATEXINLINE>$_{2}$</LATEXINLINE>^))
     </SCHEME>
     <JAVASCRIPT>
-perform(list(op("set_head"), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>)))
-perform(list(op("set_tail"), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>)))
+perform(list(op("set_head"), reg(reg1), reg(reg2)))
+perform(list(op("set_tail"), reg(reg1), reg(reg2)))
     </JAVASCRIPT>
   </SNIPPET>
   are implemented as
@@ -293,8 +293,8 @@ perform(list(op("set_tail"), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>),
       (op vector-set!) (reg the-cdrs) (reg ^reg<LATEXINLINE>$_{1}$</LATEXINLINE>^) (reg ^reg<LATEXINLINE>$_{2}$</LATEXINLINE>^))
     </SCHEME>
     <JAVASCRIPT>
-perform(op("vector_set"), list(reg("the_heads"), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>)))
-perform(op("vector_set"), list((reg("the_tails"), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>)))
+perform(op("vector_set"), list(reg("the_heads"), reg(reg1), reg(reg2)))
+perform(op("vector_set"), list((reg("the_tails"), reg(reg1), reg(reg2)))
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -322,7 +322,7 @@ perform(op("vector_set"), list((reg("the_tails"), reg(<LATEXINLINE>$\textit{reg}
       (assign ^reg<LATEXINLINE>$_{1}$</LATEXINLINE>^ (op cons) (reg ^reg<LATEXINLINE>$_{2}$</LATEXINLINE>^) (reg ^reg<LATEXINLINE>$_{3}$</LATEXINLINE>^))
     </SCHEME>
     <JAVASCRIPT>
-assign(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>, list(op("pair"), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>), reg(<LATEXINLINE>$\textit{reg}_{3}$</LATEXINLINE>))
+assign(reg1, list(op("pair"), reg(reg2), reg(reg3)))
     </JAVASCRIPT>
   </SNIPPET>
   is implemented as the following sequence of vector
@@ -339,10 +339,10 @@ assign(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>, list(op("pair"), reg(<LATE
       (assign free (op +) (reg free) (const 1))
     </SCHEME>
     <JAVASCRIPT>
-perform(op("vector_set"), list(reg("the_heads"), reg("free"), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>))),
-perform(op("vector_set"), list(reg("the_tails"), reg("free"), reg(<LATEXINLINE>$\textit{reg}_{3}$</LATEXINLINE>))),
-assign(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>, reg("free")),
-assign("free", list(op("+"), reg("free"), cons(1)))
+perform(op("vector_set"), list(reg("the_heads"), reg("free"), reg(reg2))),
+perform(op("vector_set"), list(reg("the_tails"), reg("free"), reg(reg3))),
+assign(reg1, reg("free")),
+assign("free", list(op("+"), reg("free"), constant(1)))
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -355,7 +355,7 @@ assign("free", list(op("+"), reg("free"), cons(1)))
       (op eq?) (reg ^reg<LATEXINLINE>$_{1}$</LATEXINLINE>^) (reg ^reg<LATEXINLINE>$_{2}$</LATEXINLINE>^)
     </SCHEME>
     <JAVASCRIPT>
-list(op("==="), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>), reg(<LATEXINLINE>$\textit{reg}_{2}$</LATEXINLINE>))
+list(op("==="), reg(reg1), reg(reg2))
     </JAVASCRIPT>
   </SNIPPET>
   simply tests the equality of all fields in the registers, and
@@ -382,7 +382,7 @@ list(op("==="), reg(<LATEXINLINE>$\textit{reg}_{1}$</LATEXINLINE>), reg(<LATEXIN
       (assign the-stack (op cons) (reg ^reg^) (reg the-stack))
     </SCHEME>
     <JAVASCRIPT>
-assign("the_stack", list(op("pair"), reg($\textit{reg}$), reg("the-stack")))
+assign("the_stack", list(op("pair"), reg(reg1), reg("the_stack")))
     </JAVASCRIPT>
   </SNIPPET>
   <!-- \indcodeplus{restore}{(in register machine)}[implementing]-->
@@ -404,7 +404,7 @@ assign("the_stack", list(op("tail"), reg("the_stack")))
       (assign the-stack (const ()))
     </SCHEME>
     <JAVASCRIPT>
-assign("the_stack", cons(null))
+assign("the_stack", constant(null))
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
diff --git a/xml/chapter5/section3/subsection2.xml b/xml/chapter5/section3/subsection2.xml
index 1dcec6996..5c04a1027 100644
--- a/xml/chapter5/section3/subsection2.xml
+++ b/xml/chapter5/section3/subsection2.xml
@@ -80,7 +80,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
   continue processing; new pairs will be allocated in the new working
   memory (which was the old free memory).  When this is full, we can
   copy the useful pairs into the new free memory (which was the old
-  working memory).<FOOTNOTE><P>This idea was invented and first implemented
+  working memory).<FOOTNOTE>This idea was invented and first implemented
       <INDEX>Minsky, Marvin Lee</INDEX>
       by Minsky, as part of the implementation of 
       <INDEX>Lisp<SUBINDEX>DEC@on DEC PDP-1</SUBINDEX></INDEX>
@@ -100,8 +100,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
       Hewitt, Lieberman, and Moon (see Lieberman and Hewitt
       1983) to take advantage of the fact that some structure is more volatile
       and other structure is more permanent.  
-    </P>
-    <P>
+
       An alternative commonly used garbage-collection technique is the 
       <INDEX>mark-sweep garbage collector</INDEX>
       <INDEX>garbage collector<SUBINDEX>mark-sweep</SUBINDEX></INDEX>
@@ -113,8 +112,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
       <INDEX>Allen, John</INDEX>
       discussion of the mark-sweep method can be found in 
       <CITATION>Allen 1978</CITATION>.
-    </P>
-    <P>
+
       The Minsky-Fenichel-Yochelson algorithm is the dominant algorithm in
       use for large-memory systems because it examines only the useful part
       of memory.  This is in contrast to mark-sweep, in which the sweep
@@ -128,7 +126,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
       compressed out.  This can be an extremely important performance
       consideration in machines with virtual memory, in which accesses to
       widely separated memory addresses may require extra paging
-      operations.</P></FOOTNOTE>
+      operations.</FOOTNOTE>
       </TEXT>
 
       <SUBHEADING> 
@@ -184,7 +182,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
     </SCHEME>
     <JAVASCRIPT>
       <FIGURE>
-      <FIGURE src="img_javascript/Fig5.15c.std.svg"/>
+      <FIGURE scale_factor="3" src="img_javascript/Fig5.15c.std.svg"/>
         <CAPTION>Reconfiguration of memory by the garbage-collection process.</CAPTION>
         <LABEL NAME="fig:memory-reconfig"/>
       </FIGURE>
@@ -294,7 +292,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
   there are any more objects to be scanned.  We do this by testing
   whether the <SCHEMEINLINE>scan</SCHEMEINLINE> pointer is coincident with the <SCHEMEINLINE>free</SCHEMEINLINE>
   pointer.  If the pointers are equal, then all accessible objects have
-  been relocated, and we branch to <SCHEMEINLINE>gc-flip</SCHEMEINLINE>, which cleans things up
+  been relocated, and we branch to <SPLITINLINE><SCHEMEINLINE>gc-flip</SCHEMEINLINE><JAVASCRIPTINLINE>gc_flip</JAVASCRIPTINLINE></SPLITINLINE>, which cleans things up
   so that we can continue the interrupted computation.  If there are
   still pairs to be scanned, we call the relocate subroutine to relocate
   the <SPLITINLINE><SCHEME><SCHEMEINLINE>car</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>head</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> of the next pair (by placing the <SPLITINLINE><SCHEME><SCHEMEINLINE>car</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>head</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> pointer in <SCHEMEINLINE>old</SCHEMEINLINE>).  The <SPLITINLINE><SCHEME><SCHEMEINLINE>relocate-continue</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>relocate_continue</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> register is set up so that the
@@ -351,7 +349,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
 
 "update_tail",
      perform(list(op("vector_set"), reg("new_tails"), reg("scan"), reg("new"))),
-     assign("scan", list(op("+"), reg("scan"), cons(1))),
+     assign("scan", list(op("+"), reg("scan"), constant(1))),
      go_to(label("gc_loop")),
     </JAVASCRIPT>
   </SNIPPET>
@@ -449,7 +447,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
     branch(label("already_moved")),
     assign("new", reg("free")),       // new location for pair
     // Update "free" pointer.
-    assign("free", list((op("+"), reg(free), cons(1))),
+    assign("free", list((op("+"), reg("free"), constant(1))),
     // Copy the head and tail to new memory
     perform(list(op("vector_set"), 
                  reg("new_heads"), reg("new"), reg("oldhr"))),
@@ -458,7 +456,7 @@ accumulate((x, y) => x + y, 0, filter(is_odd, enumerate_interval(0, n)))
                  reg("new_tails"), reg("new"), reg("oldhr"))),
     // Construct the broken heart
     perform(list(op("vector_set"),
-                 reg("the_heads"), reg("old"), cons("broken_heart"))),
+                 reg("the_heads"), reg("old"), constant("broken_heart"))),
     perform(list(op("vector_set"),
 		 reg("the_tails"), reg("old"), reg("new"))),
     go_to(reg("relocate_continue")),
diff --git a/xml/chapter5/section4/section4.xml b/xml/chapter5/section4/section4.xml
index 401fd8f32..b729eb2c6 100644
--- a/xml/chapter5/section4/section4.xml
+++ b/xml/chapter5/section4/section4.xml
@@ -1,4 +1,4 @@
-  <SECTION WIP="yes">
+  <SECTION WIP="no">
     <NAME>The Explicit-Control Evaluator</NAME>
 
     <SECTIONCONTENT/>
@@ -52,7 +52,7 @@
       operations to be used in our register machine.  We described the
       metacircular evaluator in terms of abstract syntax, using
       <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
-      such as <SCHEMEINLINE>quoted?</SCHEMEINLINE> and <SCHEMEINLINE>make-procedure</SCHEMEINLINE>.  In implementing the
+      such as <SPLITINLINE><SCHEME><SCHEMEINLINE>quoted?</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>is_self_evaluating</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME><SCHEMEINLINE>make-procedure</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>make_compound_function</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.  In implementing the
       register machine, we could expand these
       <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
       into sequences of
diff --git a/xml/chapter5/section4/subsection1.xml b/xml/chapter5/section4/subsection1.xml
index a3765f565..8cb3a0c45 100644
--- a/xml/chapter5/section4/subsection1.xml
+++ b/xml/chapter5/section4/subsection1.xml
@@ -22,7 +22,7 @@
     it could have been written in a data-directed style (and in a real
     system it probably would have been) to avoid the need to perform
     sequential tests and to facilitate the definition of new expression
-    types.  A machine designed to run <SPLITINLINE><SCHEME>Lisp</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE> would probably include a <SCHEMEINLINE>dispatch-on-type</SCHEMEINLINE> instruction that would efficiently execute such
+    types.  A machine designed to run <SPLITINLINE><SCHEME>Lisp</SCHEME><JAVASCRIPT>JavaScript</JAVASCRIPT></SPLITINLINE> would probably include a <SPLITINLINE><SCHEME><SCHEMEINLINE>dispatch-on-type</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>dispatch_on_type</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> instruction that would efficiently execute such
     data-directed dispatches.</FOOTNOTE>
 
   <SNIPPET EVAL="no">
@@ -51,26 +51,30 @@
     </SCHEME>
     <JAVASCRIPT>
       <!--  \indcode*{eval-dispatch} -->
-      "eval_dispatch",
-          test(op("is_self_evaluating"), reg("exp")),
-          branch(label("ev_self_eval")),
-          test(op("is_variable"), reg("exp")),
-          branch(label("ev_variable")),
-          test(op("is_quoted"), reg("exp")),
-          branch(label("ev_quoted")), /// FIXME
-          test(op("is_assignment"), reg("exp")),
-          branch(label("ev_assignment")),
-          test(op("is_definition"), reg("exp")),
-          branch(label("ev_definition")),
-          test(op("is_conditional_statement"), reg("exp")),
-          branch(label("ev_if")),
-          test(op("is_function_expression"), reg("exp")),
-          branch(label("ev_lambda")),
-          test(op("is_block"), reg("exp")),
-          branch(label("ev_begin")),
-          test(op("is_application"), reg("exp")),
-          branch(label("ev_application")),
-          go_to(label("unknown_expression_type")),
+"eval_dispatch",
+    test(op("is_self_evaluating"), reg("exp")), 
+    branch(label("ev_self_eval")),
+    test(op("is_name"), reg("exp")),
+    branch(label("ev_name")),
+    
+    test(op("is_variable_declaration"), reg("exp")),
+    branch(label("ev_variable_declaration")),
+    test(op("is_constant_declaration"), reg("exp")),
+    branch(label("ev_constant_declaration")),
+    test(op("is_assignment"), reg("exp")),
+    branch(label("ev_assignment")),
+    
+    test(op("is_conditional_expression"), reg("exp")),
+    branch(label("ev_if")),
+    test(op("is_function_definition"), reg("exp")),
+    branch(label("ev_lambda")),
+    test(op("is_sequence"), reg("exp")),
+    branch(label("ev_seq")),
+    test(op("is_block"), reg("exp")),
+    branch(label("ev_block")),
+    test(op("is_application"), reg("exp")),
+    branch(label("ev_application")),
+    go_to(label("unknown_expression_type")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -111,23 +115,20 @@
         (goto (reg continue))
       </SCHEME>
       <JAVASCRIPT>
-<!--  \indcode*{ev-self-eval} -->
 "ev_self_eval",
-    assign("val", reg("exp")),
+    assign("val", list(reg("exp"))),
     go_to(reg("continue")),
-<!--  \indcode*{ev-variable} -->
-"ev_variable",
-    assign("val", op("lookup_variable_value"), reg("exp"), reg("env")),
+    
+"ev_name",
+    assign("val", list(op("lookup_name_value"), reg("exp"), reg("env"))),
     go_to(reg("continue")),
-<!--  \indcode*{ev-quoted} -->
-"ev_quoted",
-    assign("val", op("text_of_quotation"), reg("exp")),
-    go_to(reg("continue")),
-<!--  \indcode*{ev-lambda} -->
+    
 "ev_lambda",
-    assign("unev", op("lambda_parameters"), reg("exp")),
-    assign("exp", op("lambda_body"), reg("exp")),
-    assign("val", op("make_procedure"), reg("unev"), reg("exp"), reg("env")),
+    assign("unev", list(op("function_definition_parameters"), reg("exp"))),
+    assign("exp", list(op("function_definition_body"), reg("exp"))),
+    assign("val",
+           list(op("make_compound_function"), 
+                reg("unev"), reg("exp"), reg("env"))),
     go_to(reg("continue")),
       </JAVASCRIPT>
     </SNIPPET>
@@ -193,10 +194,10 @@
   to produce a
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, which will later be applied to the evaluated
   operands.  To evaluate the operator, we move it to the <SCHEMEINLINE>exp</SCHEMEINLINE>
-  register and go to <SCHEMEINLINE>eval-dispatch</SCHEMEINLINE>.  The environment in the <SCHEMEINLINE>env</SCHEMEINLINE> register is already the correct one in which to evaluate the
+  register and go to <SPLITINLINE><SCHEMEINLINE>eval-dispatch</SCHEMEINLINE><JAVASCRIPTINLINE>eval_dispatch</JAVASCRIPTINLINE></SPLITINLINE>.  The environment in the <SCHEMEINLINE>env</SCHEMEINLINE> register is already the correct one in which to evaluate the
   operator.  However, we save <SCHEMEINLINE>env</SCHEMEINLINE> because we will need it later to
   evaluate the operands.  We also extract the operands into <SCHEMEINLINE>unev</SCHEMEINLINE>
-  and save this on the stack.  We set up <SCHEMEINLINE>continue</SCHEMEINLINE> so that <SCHEMEINLINE>eval-dispatch</SCHEMEINLINE> will resume at <SCHEMEINLINE>ev-appl-did-operator</SCHEMEINLINE> after the
+  and save this on the stack.  We set up <SCHEMEINLINE>continue</SCHEMEINLINE> so that <SPLITINLINE><SCHEMEINLINE>eval-dispatch</SCHEMEINLINE><JAVASCRIPTINLINE>eval_dispatch</JAVASCRIPTINLINE></SPLITINLINE> will resume at <SPLITINLINE><SCHEMEINLINE>ev-appl-did-operator</SCHEMEINLINE><JAVASCRIPTINLINE>ev_appl_did_operator</JAVASCRIPTINLINE></SPLITINLINE> after the
   operator has been evaluated.  First, however, we save the old value of
   <SCHEMEINLINE>continue</SCHEMEINLINE>, which tells the controller where to continue after the
   application.
@@ -214,15 +215,14 @@
       (goto (label eval-dispatch))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{ev-application} -->
-      "ev_application",
-          save("continue"),
-          save("env"),
-          assign("unev", op("operands"), reg("exp")),
-          save("unev"),
-          assign("exp", op("operator"), reg("exp")),
-          assign("continue", label("ev_appl_did_operator")),
-          go_to(label("eval_dispatch")),
+"ev_application",
+    save("continue"),
+    save("env"),
+    assign("unev", list(op("operands"), reg("exp"))),
+    save("unev"),
+    assign("exp", list(op("operator"), reg("exp"))),
+    assign("continue", label("ev_appl_did_operator")),
+    go_to(label("eval_dispatch")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -235,7 +235,7 @@
   the unevaluated operands and the environment.  We initialize <SCHEMEINLINE>argl</SCHEMEINLINE> to an empty list.  Then we assign to the <SCHEMEINLINE>proc</SCHEMEINLINE> register the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   that was produced by evaluating the operator.  If there are
-  no operands, we go directly to <SCHEMEINLINE>apply-dispatch</SCHEMEINLINE>.  Otherwise we
+  no operands, we go directly to <SPLITINLINE><SCHEMEINLINE>apply-dispatch</SCHEMEINLINE><JAVASCRIPTINLINE>apply_dispatch</JAVASCRIPTINLINE></SPLITINLINE>.  Otherwise we
   save <SCHEMEINLINE>proc</SCHEMEINLINE> on the stack and start the argument-evaluation
   loop:<FOOTNOTE>We add to the evaluator data-structure
     <SPLITINLINE><SCHEME>procedures</SCHEME><JAVASCRIPT>functions</JAVASCRIPT></SPLITINLINE>
@@ -294,14 +294,14 @@ function is_last_operand(ops) {
       (save proc)
     </SCHEME>
     <JAVASCRIPT>
-      "ev_appl_did_operator",
-           restore("unev"),                  // the operands
-           restore("env"),
-           assign("argl", op("empty_arglist")),
-           assign("fun", reg("val")),       // the operator
-           test(op("has_no_operands"), reg("unev")),
-           branch(label("apply_dispatch")),
-           save("fun"),
+"ev_appl_did_operator",
+    restore("unev"), // the operands
+    restore("env"),
+    assign("argl", list(op("empty_arglist"))),
+    assign("fun", list(reg("val"))), // the operator
+    test(op("has_no_operands"), reg("unev")),
+    branch(label("apply_dispatch")),
+    save("fun"),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -330,15 +330,15 @@ function is_last_operand(ops) {
       (goto (label eval-dispatch))
     </SCHEME>
     <JAVASCRIPT>
-       "ev_appl_operand_loop",
-           save("argl"),
-           assign("exp", (op("first_operand"), reg("unev")),
-           test(op("is_last_operand"), reg("unev")),
-           branch(label("ev_appl_last_arg")),
-           save("env"),
-           save("unev"),
-           assign("continue", (label("ev_appl_accumulate_arg"))),
-           go_to(label("eval_dispatch")),
+"ev_appl_operand_loop",
+    save("argl"),
+    assign("exp", list(op("first_operand"), reg("unev"))),
+    test(op("is_last_operand"), reg("unev")),
+    branch(label("ev_appl_last_arg")),
+    save("env"),
+    save("unev"),
+    assign("continue", label("ev_appl_accumulate_arg")),
+    go_to(label("eval_dispatch")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -359,13 +359,13 @@ function is_last_operand(ops) {
       (goto (label ev-appl-operand-loop))
     </SCHEME>
     <JAVASCRIPT>
-      "ev_appl_accumulate_arg",
-          restore("unev"),
-          restore("env"),
-          restore("argl"),
-          assign("argl", op("adjoin_arg"), reg("val"), reg("argl")),
-          assign("unev", op("rest_operands"), reg("unev")),
-          go_to(label("ev_appl_operand_loop")),
+"ev_appl_accumulate_arg",
+    restore("unev"),
+    restore("env"),
+    restore("argl"),
+    assign("argl", list(op("adjoin_arg"), reg("val"), reg("argl"))),
+    assign("unev", list(op("rest_operands"), reg("unev"))),
+    go_to(label("ev_appl_operand_loop")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -373,9 +373,9 @@ function is_last_operand(ops) {
       <TEXT>
   Evaluation of the last argument is handled differently.  There is no
   need to save the environment or the list of unevaluated operands
-  before going to <SCHEMEINLINE>eval-dispatch</SCHEMEINLINE>,
+  before going to <SPLITINLINE><SCHEMEINLINE>eval-dispatch</SCHEMEINLINE><JAVASCRIPTINLINE>eval_dispatch</JAVASCRIPTINLINE></SPLITINLINE>,
   since they will not be required after the last operand is evaluated.
-  Thus, we return from the evaluation to a special entry point <SCHEMEINLINE>ev-appl-accum-last-arg</SCHEMEINLINE>, which restores the argument list, accumulates
+  Thus, we return from the evaluation to a special entry point <SPLITINLINE><SCHEME><SCHEMEINLINE>ev-appl-accum-last-arg</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>ev_appl_accum_last_arg</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, which restores the argument list, accumulates
   the new argument, restores the saved
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, and goes off to
   perform the 
@@ -390,7 +390,7 @@ function is_last_operand(ops) {
     initializing <SCHEMEINLINE>argl</SCHEMEINLINE> until after evaluating the first operand, so
     as to avoid saving <SCHEMEINLINE>argl</SCHEMEINLINE> in this case.  The compiler in
     section<SPACE/><REF NAME="sec:compilation"/> performs this optimization.  (Compare
-    the <SCHEMEINLINE>construct-arglist</SCHEMEINLINE>
+    the <SPLITINLINE><SCHEME><SCHEMEINLINE>construct-arglist</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>construct_arglist</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
     <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
     of
     section<SPACE/><REF NAME="sec:compiling-combinations"/>.)</FOOTNOTE>
@@ -408,14 +408,14 @@ function is_last_operand(ops) {
     </SCHEME>
     <JAVASCRIPT>
 "ev_appl_last_arg",
-      assign("continue", label("ev_appl_accum_last_arg")),
-      go_to(label("eval_dispatch")),
-
+    assign("continue", label("ev_appl_accum_last_arg")),
+    go_to(label("eval_dispatch")),
+    
 "ev_appl_accum_last_arg",
-      restore(argl),
-      assign("argl", op("adjoin_arg"), reg("val"), reg("argl")),
-      restore("fun"),
-      go_to(label("apply_dispatch")),
+    restore("argl"),
+    assign("argl", list(op("adjoin_arg"), reg("val"), reg("argl"))),
+    restore("fun"),
+    go_to(label("apply_dispatch")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -432,10 +432,10 @@ function is_last_operand(ops) {
     determined by the order of evaluation of the arguments to <SPLITINLINE><SCHEME><SCHEMEINLINE>cons</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>pair</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
     in the
     <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-    <SCHEMEINLINE>list-of-values</SCHEMEINLINE> of section<SPACE/><REF NAME="sec:core-of-evaluator"/>
-    (see exercise<SPACE/><REF NAME="ex:arg-eval-order"/>).</FOOTNOTE> Because the <SCHEMEINLINE>first\?operand</SCHEMEINLINE>
-  selector (used in <SCHEMEINLINE>ev-appl-operand-loop</SCHEMEINLINE> to extract successive operands
-  from <SCHEMEINLINE>unev</SCHEMEINLINE>) is implemented as <SPLITINLINE><SCHEME><SCHEMEINLINE>car</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>head</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and the <SCHEMEINLINE>rest-operands</SCHEMEINLINE> selector is implemented as <SPLITINLINE><SCHEME><SCHEMEINLINE>cdr</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>tail</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, the
+    <SPLITINLINE><SCHEME><SCHEMEINLINE>list-of-values</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>list_of_values</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> of section<SPACE/><REF NAME="sec:core-of-evaluator"/>
+    (see exercise<SPACE/><REF NAME="ex:arg-eval-order"/>).</FOOTNOTE> Because the <SPLITINLINE><SCHEME><SCHEMEINLINE>first-operand</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>first_operand</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
+  selector (used in <SPLITINLINE><SCHEME><SCHEMEINLINE>ev-appl-operand-loop</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>ev_appl_operand_loop</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to extract successive operands
+  from <SCHEMEINLINE>unev</SCHEMEINLINE>) is implemented as <SPLITINLINE><SCHEME><SCHEMEINLINE>car</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>head</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and the <SPLITINLINE><SCHEME><SCHEMEINLINE>rest-operands</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>rest_operands</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> selector is implemented as <SPLITINLINE><SCHEME><SCHEMEINLINE>cdr</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>tail</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, the
   explicit-control evaluator will evaluate the operands of a combination
   in left-to-right order.
   <INDEX>explicit-control evaluator for Scheme<SUBINDEX>operand evaluation|)</SUBINDEX></INDEX>
@@ -448,14 +448,14 @@ function is_last_operand(ops) {
 
       <LABEL NAME="sec:procedure-application"/>
       <TEXT>
-  The entry point <SCHEMEINLINE>apply-dispatch</SCHEMEINLINE> corresponds to the <SCHEMEINLINE>apply</SCHEMEINLINE>
+  The entry point <SPLITINLINE><SCHEME><SCHEMEINLINE>apply-dispatch</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>apply_dispatch</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> corresponds to the <SCHEMEINLINE>apply</SCHEMEINLINE>
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  of the metacircular evaluator.  By the time we get to <SCHEMEINLINE>apply-dispatch</SCHEMEINLINE>, the <SCHEMEINLINE>proc</SCHEMEINLINE> register contains the
+  of the metacircular evaluator.  By the time we get to <SPLITINLINE><SCHEME><SCHEMEINLINE>apply-dispatch</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>apply_dispatch</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, the <SCHEMEINLINE>proc</SCHEMEINLINE> register contains the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   to
   apply and <SCHEMEINLINE>argl</SCHEMEINLINE> contains the list of evaluated arguments to which
   it must be applied.  The saved value of <SCHEMEINLINE>continue</SCHEMEINLINE> (originally
-  passed to <SCHEMEINLINE>eval-dispatch</SCHEMEINLINE> and saved at <SCHEMEINLINE>ev-application</SCHEMEINLINE>),
+  passed to <SPLITINLINE><SCHEME><SCHEMEINLINE>eval-dispatch</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>eval_dispatch</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and saved at <SPLITINLINE><SCHEME><SCHEMEINLINE>ev-application</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>ev_application</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>),
   which tells where to return with the result of the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   application, is on the stack.  When the application is complete, the
@@ -477,13 +477,12 @@ function is_last_operand(ops) {
       (goto (label unknown-procedure-type))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{apply-dispatch} -->
-      "apply_dispatch",
-          test(op("is_primitive_procedure"), reg("fun")),
-          branch(label("primitive_apply")),
-          test(op("is_compound_procedure"), reg("fun")),
-          branch(label("compound_apply")),
-          go_to(label("unknown_procedure_type")),
+"apply_dispatch",
+    test(op("is_primitive_function"), reg("fun")),
+    branch(label("primitive_apply")),
+    test(op("is_compound_function"), reg("fun")),
+    branch(label("compound_apply")),
+    go_to(label("unknown_procedure_type")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -511,13 +510,13 @@ function is_last_operand(ops) {
   </SPLITINLINE>
   Since we are interested in the structure of
   the evaluation process rather than the details of the primitives, we
-  will instead just use an <SCHEMEINLINE>apply-primitive-procedure</SCHEMEINLINE> operation
+  will instead just use an <SPLITINLINE><SCHEME><SCHEMEINLINE>apply-primitive-procedure</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>apply_primitive_procedure</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> operation
   that applies the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   in <SCHEMEINLINE>proc</SCHEMEINLINE> to the arguments in <SCHEMEINLINE>argl</SCHEMEINLINE>.  For the purpose of simulating the evaluator with the simulator
   of section<SPACE/><REF NAME="sec:simulator"/> we use the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
-  <SCHEMEINLINE>apply-primitive-procedure</SCHEMEINLINE>, which calls on the underlying Scheme
+  <SPLITINLINE><SCHEME><SCHEMEINLINE>apply-primitive-procedure</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>apply_primitive_procedure</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, which calls on the underlying Scheme
   system to perform the application, just as we did for the metacircular
   evaluator in section<SPACE/><REF NAME="sec:running-eval"/>.  After computing the
   value of the primitive application, we restore <SCHEMEINLINE>continue</SCHEMEINLINE> and go
@@ -534,11 +533,13 @@ function is_last_operand(ops) {
       (goto (reg continue))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{primitive-apply} -->
-      "primitive_apply",
-          assign("val", op("apply_primitive_procedure"), reg("fun"), reg("argl")),
-          restore("continue"),
-          go_to(reg("continue")),
+"primitive_apply",
+    assign(
+    "val",
+    list(op("apply_primitive_function"), reg("fun"), reg("argl"))
+    ),
+    restore("continue"),
+    go_to(reg("continue")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -554,7 +555,7 @@ function is_last_operand(ops) {
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>, and evaluate in this
   extended environment the sequence of expressions that forms the body
   of the
-  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  <SCHEMEINLINE>Ev-sequence</SCHEMEINLINE>, described below in
+  <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  <SPLITINLINE><SCHEME><SCHEMEINLINE>Ev-sequence</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Ev_sequence</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>, described below in
   section<SPACE/><REF NAME="sec:sequence-evaluation"/>, handles the evaluation
   of the sequence.
 
@@ -570,19 +571,32 @@ function is_last_operand(ops) {
       (goto (label ev-sequence))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{compound-apply} -->
-      "compound_apply",
-          assign("unev", op("procedure_parameters"), reg("fun")),
-          assign("env", op("procedure_environment") reg("fun")),
-          assign("env", op("extend_environment"), reg("unev"), reg("argl"), reg("env")),
-          assign("unev", op("procedure_body"), reg("fun")),
-          go_to(label("ev_sequence")),
+"compound_apply",
+    assign("unev", list(op("function_parameters"), reg("fun"))), // params
+    // FIXME: A QUICK HACK HERE, UNSURE WHY IT'S NEEDED
+    assign("unev", list(op("all_names_of_names"), reg("unev"))), // params destructured
+    
+    assign("temp", list(op("function_body"), reg("fun"))), // body
+    assign("temp", list(op("local_names"), reg("unev"))), // locals
+    
+    assign("unev", list(op("insert_all"), reg("unev"), reg("temp"))), //names
+    assign("temp", list(op("get_temp_block_values"), reg("temp"))), // temp_values
+    
+    assign("temp", list(op("append"), reg("argl"), reg("temp"))), // values
+    assign("env", list(op("function_environment"), reg("fun"))),
+    
+    assign(
+    "env",
+    list(op("extend_environment"), reg("unev"), reg("temp"), reg("env"))
+    ),
+    assign("unev", list(op("function_body"), reg("fun"))),
+    go_to(label("ev_sequence")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
 
       <TEXT>
-  <SCHEMEINLINE>Compound-apply</SCHEMEINLINE> is the only place in the interpreter where the
+  <SPLITINLINE><SCHEME><SCHEMEINLINE>Compound-apply</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Compound_apply</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is the only place in the interpreter where the
   <SCHEMEINLINE>env</SCHEMEINLINE> register is ever assigned a new value.  Just as in the
   metacircular evaluator, the new environment is constructed from the
   environment carried by the
diff --git a/xml/chapter5/section4/subsection2.xml b/xml/chapter5/section4/subsection2.xml
index ac9e912c6..5b8c8f88f 100644
--- a/xml/chapter5/section4/subsection2.xml
+++ b/xml/chapter5/section4/subsection2.xml
@@ -7,7 +7,7 @@
       <INDEX>explicit-control evaluator for Scheme<SUBINDEX>sequences of expressions|(</SUBINDEX></INDEX>
 
       <TEXT>
-  The portion of the explicit-control evaluator at <SPLITINLINE><SCHEME><SCHEMEINLINE>ev-sequence</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>ev-sequence</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is
+  The portion of the explicit-control evaluator at <SPLITINLINE><SCHEME><SCHEMEINLINE>ev-sequence</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>ev_sequence</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> is
   analogous to the metacircular evaluator<APOS/>s <SPLITINLINE><SCHEME><SCHEMEINLINE>eval-sequence</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>eval_sequence</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>.  It
   handles sequences of expressions in
@@ -86,23 +86,28 @@
       (goto (label eval-dispatch))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{ev-sequence}[with tail recursion] -->
-      "ev_sequence",
-          assign(exp(op("first_exp"), reg("unev"))),
-          test(op("is_last_exp"), reg("unev")),
-          branch(label("ev_sequence_last_exp")),
-          save("unev"),
-          save("env"),
-          assign("continue", label("ev_sequence_continue")),
-          go_to(label("eval_dispatch")),
-      "ev_sequence_continue",
-          restore("env"),
-          restore("unev"),
-          assign("unev", op("rest_exps"), reg("unev")),
-          go_to(label("ev_sequence")),
-      "ev_sequence_last_exp",
-          restore("continue"),
-          go_to(label("eval_dispatch")),
+"ev_seq", //FIXME: not part of original book -- explain why needed
+    save("continue"),
+    assign("unev", list(op("sequence_statements"), reg("exp"))),
+    
+"ev_sequence",
+    assign("exp", list(op("first_statement"), reg("unev"))),
+    test(op("is_last_statement"), reg("unev")),
+    branch(label("ev_sequence_last_exp")),
+    save("unev"),
+    save("env"),
+    assign("continue", label("ev_sequence_continue")),
+    go_to(label("eval_dispatch")),
+    
+"ev_sequence_continue",
+    restore("env"),
+    restore("unev"),
+    assign("unev", list(op("rest_statements"), reg("unev"))),
+    go_to(label("ev_sequence")),
+    
+"ev_sequence_last_exp",
+    restore("continue"),
+    go_to(label("eval_dispatch")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -127,11 +132,11 @@
             x)))
     </SCHEME>
     <JAVASCRIPT>
-      function sqrt_iter(guess, x) {
-          return is_good_enough(guess, x)
-              ? guess
-              : sqrt_iter(improve(guess, x), x);
-      }
+function sqrt_iter(guess, x) {
+    return is_good_enough(guess, x)
+        ? guess
+        : sqrt_iter(improve(guess, x), x);
+}
     </JAVASCRIPT>
   </SNIPPET>
   is an iterative process.  Even though the
@@ -201,9 +206,9 @@
         (define (no-more-exps? seq) (null? seq))
       </SCHEME>
       <JAVASCRIPT>
-        function has_no_more_exps(seq) {
-            return is_null(seq);
-        }
+function has_no_more_exps(seq) {
+    return is_null(seq);
+}
       </JAVASCRIPT>
   </SNIPPET>
   </FOOTNOTE>
@@ -229,23 +234,23 @@
       (goto (reg continue))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{ev-sequence}[without tail recursion] -->
-      "ev_sequence",
-          test(op("has_no_more_exps"), reg("unev")),
-          branch(label("ev_sequence_end")),
-          assign(exp(op("first_exp"), reg("unev")),
-          save("unev"),
-          save("env"),
-          assign(continue(label("ev_sequence_continue"))),
-          go_to(label("eval_dispatch")),
-      "ev_sequence_continue",
-          restore("env"),
-          restore("unev"),
-          assign("unev", op("rest_exps"), reg("unev")),
-          go_to(label("ev_sequence")),
-      "ev_sequence_end",
-          restore("continue"),
-          go_to(reg("continue")),
+<!--  \indcode*{ev-sequence}[without tail recursion] -->
+"ev_sequence",
+     test(op("has_no_more_exps"), reg("unev")),
+     branch(label("ev_sequence_end")),
+     assign(exp(op("first_exp"), reg("unev")),
+     save("unev"),
+     save("env"),
+     assign(continue(label("ev_sequence_continue"))),
+     go_to(label("eval_dispatch")),
+"ev_sequence_continue",
+     restore("env"),
+     restore("unev"),
+     assign("unev", op("rest_exps"), reg("unev")),
+     go_to(label("ev_sequence")),
+"ev_sequence_end",
+     restore("continue"),
+     go_to(reg("continue")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -278,10 +283,10 @@
       (count (+ n 1)))
     </SCHEME>
     <JAVASCRIPT>
-      function count(n) {
-          display(n, "\n");
-          count(n + 1);
-      }
+function count(n) {
+    display(n, "\n");
+    count(n + 1);
+}
     </JAVASCRIPT>
   </SNIPPET>
   Without tail recursion, such a
diff --git a/xml/chapter5/section4/subsection3.xml b/xml/chapter5/section4/subsection3.xml
index c711911ef..3c1b5190e 100644
--- a/xml/chapter5/section4/subsection3.xml
+++ b/xml/chapter5/section4/subsection3.xml
@@ -32,14 +32,14 @@
       (goto (label eval-dispatch))  <EM>; evaluate the predicate</EM>
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{ev-if} -->
-      "ev_if",
-          save("exp"),                    // save expression for later
-          save("env"),
-          save("continue"),
-          assign("continue", label("ev_if_decide")),
-          assign("exp", op("if_predicate"), reg("exp")),
-          go_to(label("eval_dispatch")),  // evaluate the predicate
+<!--  \indcode*{ev-if} -->
+"ev_if",
+    save("exp"),                    // save expression for later
+    save("env"),
+    save("continue"),
+    assign("continue", label("ev_if_decide")),
+    assign("exp", list(op("conditional_pred"), reg("exp"))),
+    go_to(label("eval_dispatch")),  // evaluate the predicate
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -68,20 +68,20 @@
       (goto (label eval-dispatch))
     </SCHEME>
     <JAVASCRIPT>
-      "ev_if_decide",
-          restore("continue"),
-          restore("env"),
-          restore("exp"),
-          test(op("is_true"), reg("val")),
-          branch(label("ev_if_consequent")),
-
-      "ev_if_alternative",
-          assign("exp", op("if_alternative"), reg("exp")),
-          go_to(label("eval_dispatch")),
-
-      "ev_if_consequent",
-          assign("exp", op("if_consequent"), reg("exp")),
-          go_to(label("eval_dispatch")),
+"ev_if_decide",
+    restore("continue"),
+    restore("env"),
+    restore("exp"),
+    test(op("is_true"), reg("val")),
+    branch(label("ev_if_consequent")),
+    
+"ev_if_alternative",
+    assign("exp", list(op("conditional_alt"), reg("exp"))),
+    go_to(label("eval_dispatch")),
+    
+"ev_if_consequent",
+    assign("exp", list(op("conditional_cons"), reg("exp"))),
+    go_to(label("eval_dispatch")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -118,23 +118,25 @@
       (goto (reg continue))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{ev-assignment} -->
-      "ev_assignment",
-          assign("unev", op("assignment_variable"), reg("exp")),
-          save("unev"),                   // save variable for later
-          assign("exp", op("assignment_value"), reg("exp")),
-          save("env"),
-          save("continue"),
-          assign("continue", label("ev_assignment_1")),
-          go_to(label("eval_dispatch")),  // evaluate the assignment value
-
-      "ev_assignment_1",
-          restore("continue"),
-          restore("env"),
-          restore("unev"),
-          perform(op("set_variable_value"), reg("unev"), reg("val"), reg("env")),
-          assign("val", const("ok")),
-          go_to(reg("continue")),
+<!--  \indcode*{ev-assignment} -->
+"ev_assignment",
+    assign("unev", list(op("assignment_name"), reg("exp"))),
+    save("unev"), // save variable for later
+    assign("exp", list(op("assignment_value"), reg("exp"))),
+    save("env"),
+    save("continue"),
+    assign("continue", label("ev_assignment_1")),
+    go_to(label("eval_dispatch")), // evaluate the assignment value
+    
+"ev_assignment_1",
+    restore("continue"),
+    restore("env"),
+    restore("unev"),
+    perform(
+    list(op("assign_name_value"), reg("unev"), reg("val"), reg("env"))
+    ),
+    assign("val", list(constant("ok"))),
+    go_to(reg("continue")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -163,23 +165,23 @@
       (goto (reg continue))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{ev-definition} -->
-      "ev-definition",
-          assign("unev", op("definition-variable"), reg("exp")),
-          save("unev"),                   // save variable for later
-          assign("exp", op("definition-value"), reg("exp")),
-          save("env"),
-          save("continue"),
-          assign("continue", label("ev-definition-1")),
-          go_to(label("eval-dispatch")),  // evaluate the definition value
-
-      "ev-definition-1",
-          restore("continue"),
-          restore("env"),
-          restore("unev"),
-          perform(op("define-variable"), reg("unev"), reg("val"), reg("env")),
-          assign("val", const("ok")),
-          go_to(reg("continue")),
+<!--  \indcode*{ev-definition} -->
+"ev_variable_declaration",
+    assign("unev", list(op("variable_declaration_name"), reg("exp"))),
+    save("unev"), // save variable for later
+    assign("exp", list(op("variable_declaration_value"), reg("exp"))),
+    save("env"),
+    save("continue"),
+    assign("continue", label("ev_variable_declaration_1")),
+    go_to(label("eval_dispatch")), // evaluate the declaration value
+    
+"ev_variable_declaration_1",
+    restore("continue"),
+    restore("env"),
+    restore("unev"),
+    perform(list(op("declare_value"), reg("unev"), reg("val"), reg("env"))),
+    assign("val", list(constant("ok"))),
+    go_to(reg("continue")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -205,7 +207,7 @@
   Implement <SCHEMEINLINE>cond</SCHEMEINLINE> as a new basic special form without
   reducing it to <SCHEMEINLINE>if</SCHEMEINLINE>.  You will have to construct a loop that tests
   the predicates of successive <SCHEMEINLINE>cond</SCHEMEINLINE> clauses until you find one
-  that is true, and then use <SCHEMEINLINE>ev-sequence</SCHEMEINLINE> to evaluate the actions
+  that is true, and then use <SPLITINLINE><SCHEME><SCHEMEINLINE>ev-sequence</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>ev_sequence</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to evaluate the actions
   of the clause.
   <LABEL NAME="ex:eceval-cond"/>
       </EXERCISE>
diff --git a/xml/chapter5/section4/subsection4.xml b/xml/chapter5/section4/subsection4.xml
index c80b95b70..8d3402d83 100644
--- a/xml/chapter5/section4/subsection4.xml
+++ b/xml/chapter5/section4/subsection4.xml
@@ -89,19 +89,21 @@ function get_global_environment() {
     </SCHEME>
     <JAVASCRIPT>
       <INDEX>prompts<SUBINDEX>explicit-control evaluator</SUBINDEX></INDEX>
-      <!--  \indcode*{read-eval-print-loop} -->
-      "read_eval_print_loop",
-          perform(op("initialize_stack")),
-          perform(op("prompt_for_input"), const("/// EC_Eval input:")),
-          assign("exp", op("read")),
-          assign("env", op("get_global_environment")),
-          assign("continue", label("print_result")),
-          go_to(label("eval_dispatch")),
-          <!__  \indcode*{print_result} __>
-      "print_result",
-          perform(op("announce_output"), const(";;; EC_Eval value:")),
-          perform(op("user_print"), reg("val")),
-          go_to(label("read_eval_print_loop")),
+<!--  \indcode*{read-eval-print-loop} -->
+/// FIXME: missing from PR39
+"read_eval_print_loop",
+    perform(op("initialize_stack")),
+    perform(op("prompt_for_input"), const("/// EC_Eval input:")),
+    assign("exp", op("read")),
+    assign("env", op("get_global_environment")),
+    assign("continue", label("print_result")),
+    go_to(label("eval_dispatch")),
+
+<!--  \indcode*{print_result} -->
+"print_result",
+    perform(op("announce_output"), const(";;; EC_Eval value:")),
+    perform(op("user_print"), reg("val")),
+    go_to(label("read_eval_print_loop")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -137,21 +139,21 @@ function get_global_environment() {
       (goto (label read-eval-print-loop))
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{unknown-expression-type} -->
-      "unknown_expression_type",
-          assign("val", const("unknown_expression_type_error")),
-          go_to(label("signal_error")),
-
-      <!--  \indcode*{unknown-procedure-type} -->
-      "unknown_procedure_type",
-          restore("continue"),    /// clean up stack (from apply_dispatch)
-          assign(val(const("unknown_procedure_type_error"))),
-          go_to(label("signal_error")),
-
-      <!--  \indcode*{signal-error} -->
-      "signal_error",
-          perform(op("user_print"), reg("val")),
-          go_to(label("read_eval_print_loop")),
+<!--  \indcode*{unknown-expression-type} -->
+"unknown_expression_type",
+    assign("val", list(constant("unknown_expression_type_error"))),
+    go_to(label("signal_error")),
+    
+<!--  \indcode*{unknown-procedure-type} -->
+"unknown_procedure_type",
+    restore("continue"), /// clean up stack (from apply_dispatch)
+    assign("val", list(constant("unknown_procedure_type_error"))),
+    go_to(label("signal_error")),
+    
+<!--  \indcode*{signal-error} -->
+"signal_error",
+    perform(list(op("user_print"), reg("val"))),
+    go_to(label("evaluator_done")),
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -186,7 +188,7 @@ function get_global_environment() {
     </SCHEME>
     <JAVASCRIPT>
 function eceval() {
-    return make_machine(list("exp", "env", "val", "proc", "argl", "continue", "unev"),
+    return make_machine(list("exp", "env", "val", "proc", "argl", "continue", "unev", "temp"), // FIXME: remove temp?
                         eceval_operations,
                         list(read_eval_print_loop,
                              ... /* entire machine controller as given above */ 
@@ -244,6 +246,1702 @@ const eceval_operations =
       ;;; EC-Eval value:
       (a b c d e f)
     </SCHEMEOUTPUT>
+    <EXPECTED>
+24
+    </EXPECTED>
+    <JAVASCRIPT_RUN>
+/*
+  Explicit control evaluator for Source §1 sublanguage
+
+  This is an "explicit control evaluator", that is, a register machine that acts as a meta-circular evaluator.
+  It is described in 5.4 of SICP JS (https://sicp.comp.nus.edu.sg/chapters/109#top).
+
+  An example usage:
+  ```
+  set_program_to_run("1 + 3 * 4;");   // This parses the program and loads it into the register machine
+  start(m);                           // This runs the register machine
+  get_register_contents(m, "val");    // The output is in the register named "val"
+  ```
+
+  The Source §1 evaluator skeleton code is in lines 20-558
+  The skeleton code for a register machine is in lines 560-1160
+  The register machine is in the function "evaluator_machine" (lines 1162-1671)
+*/
+
+/*
+  Evaluator for language with booleans, conditionals,
+  sequences, functions, constants, variables and blocks
+  This is an evaluator for a language that lets you declare
+  functions, variables and constants, apply functions, and
+  carry out simple arithmetic calculations, boolean operations.
+  The covered Source §1 sublanguage is:
+  stmt    ::= const name = expr ; 
+  |  let name = expr ; 
+  |  function name(params) block
+  |  expr ; 
+  |  stmt stmt
+  |  name = expr ; 
+  |  block
+  block   ::= { stmt }
+  expr    ::= expr ? expr : expr
+  |  expr binop expr
+  |  unop expr
+  |  name
+  |  number
+  |  expr(expr, expr, ...)
+  binop   ::= + | - | * | / | % | &lt; | &gt; | &lt;= | &gt;= 
+  | === | !== |  &amp;&amp; | ||
+  unop    ::= ! | -
+*/
+
+/* CONSTANTS: NUMBERS, STRINGS, TRUE, FALSE */
+
+// constants (numbers, strings, booleans)
+// are considered "self_evaluating". This means, they
+// represent themselves in the syntax tree
+
+function is_self_evaluating(stmt) {
+    return is_number(stmt) || is_string(stmt) || is_boolean(stmt);
+}
+
+// all other statements and expressions are
+// tagged lists. Their tag tells us what
+// kind of statement/expression they are
+
+function is_tagged_list(stmt, the_tag) {
+    return is_pair(stmt) &amp;&amp; head(stmt) === the_tag;
+}
+
+/* NAMES */
+
+// In this evaluator, the operators are referred
+// to as "names" in expressions.
+
+// Names are tagged with "name".
+// In this evaluator, typical names
+// are
+// list("name", "+")
+// list("name", "factorial")
+// list("name", "n")
+
+function is_name(stmt) {
+    return is_tagged_list(stmt, "name");
+}
+function name_of_name(stmt) {
+    return head(tail(stmt));
+}
+
+/* CONSTANT DECLARATIONS */
+
+// constant declarations are tagged with "constant_declaration"
+// and have "name" and "value" properties
+
+function is_constant_declaration(stmt) {
+    return is_tagged_list(stmt, "constant_declaration");
+}
+function constant_declaration_name(stmt) {
+    return head(tail(head(tail(stmt))));
+}
+function constant_declaration_value(stmt) {
+    return head(tail(tail(stmt)));
+}
+
+/* VARIABLE DECLARATIONS */
+
+function is_variable_declaration(stmt) {
+    return is_tagged_list(stmt, "variable_declaration");
+}
+function variable_declaration_name(stmt) {
+    return head(tail(head(tail(stmt))));
+}
+function variable_declaration_value(stmt) {
+    return head(tail(tail(stmt)));
+}
+
+/* CONDITIONAL EXPRESSIONS */
+
+// conditional expressions are tagged
+// with "conditional_expression"
+
+function is_conditional_expression(stmt) {
+    return is_tagged_list(stmt, "conditional_expression");
+}
+function cond_expr_pred(stmt) {
+    return list_ref(stmt, 1);
+}
+function cond_expr_cons(stmt) {
+    return list_ref(stmt, 2);
+}
+function cond_expr_alt(stmt) {
+    return list_ref(stmt, 3);
+}
+function is_true(x) {
+    return x === true;
+}
+
+/* FUNCTION DEFINITION EXPRESSIONS */
+
+// function definitions are tagged with "function_definition"
+// have a list of "parameters" and a "body" statement
+
+function is_function_definition(stmt) {
+    return is_tagged_list(stmt, "function_definition");
+}
+function function_definition_parameters(stmt) {
+    return head(tail(stmt));
+}
+function function_definition_body(stmt) {
+    return head(tail(tail(stmt)));
+}
+
+// compound function values keep track of parameters, body
+// and environment, in a list tagged as "compound_function"
+
+function make_compound_function(parameters, body, env) {
+    return list("compound_function", parameters, body, env);
+}
+function is_compound_function(f) {
+    return is_tagged_list(f, "compound_function");
+}
+function function_parameters(f) {
+    return list_ref(f, 1);
+}
+function function_body(f) {
+    return list_ref(f, 2);
+}
+function function_environment(f) {
+    return list_ref(f, 3);
+}
+
+// evaluating a function definition expression
+// results in a function value. Note that the
+// current environment is stored as the function
+// value's environment
+
+function eval_function_definition(stmt, env) {
+    return make_compound_function(
+        map(name_of_name, function_definition_parameters(stmt)),
+        function_definition_body(stmt),
+        env
+    );
+}
+
+/* SEQUENCES */
+
+// sequences of statements are just represented
+// by tagged lists of statements by the parser.
+
+function is_sequence(stmt) {
+    return is_tagged_list(stmt, "sequence");
+}
+function make_sequence(stmts) {
+    return list("sequence", stmts);
+}
+function sequence_statements(stmt) {
+    return head(tail(stmt));
+}
+function is_empty_sequence(stmts) {
+    return is_null(stmts);
+}
+function is_last_statement(stmts) {
+    return is_null(tail(stmts));
+}
+function first_statement(stmts) {
+    return head(stmts);
+}
+function rest_statements(stmts) {
+    return tail(stmts);
+}
+
+/* FUNCTION APPLICATION */
+
+// The core of our evaluator is formed by the
+// implementation of function applications.
+// Applications are tagged with "application"
+// and have "operator" and "operands"
+
+function is_application(stmt) {
+    return is_tagged_list(stmt, "application");
+}
+function operator(stmt) {
+    return head(tail(stmt));
+}
+function operands(stmt) {
+    return head(tail(tail(stmt)));
+}
+function no_operands(ops) {
+    return is_null(ops);
+}
+function first_operand(ops) {
+    return head(ops);
+}
+function rest_operands(ops) {
+    return tail(ops);
+}
+
+// primitive functions are tagged with "primitive"
+// and come with a Source function "implementation"
+
+function make_primitive_function(impl) {
+    return list("primitive", impl);
+}
+function is_primitive_function(fun) {
+    return is_tagged_list(fun, "primitive");
+}
+function primitive_implementation(fun) {
+    return list_ref(fun, 1);
+}
+
+/* APPLY */
+
+// apply_in_underlying_javascript allows us
+// to make use of JavaScript's primitive functions
+// in order to access operators such as addition
+
+function apply_primitive_function(fun, argument_list) {
+    return apply_in_underlying_javascript(
+        primitive_implementation(fun),
+        argument_list
+    );
+}
+
+// We use a nullary function as temporary value for names whose
+// declaration has not yet been evaluated. The purpose of the
+// function definition is purely to create a unique identity;
+// the function will never be applied and its return value
+// (null) is irrelevant.
+const no_value_yet = () => null;
+
+// The function local_names collects all names declared in the
+// body statements. For a name to be included in the list of
+// local_names, it needs to be declared outside of any other
+// block or function.
+
+function insert_all(xs, ys) {
+    return is_null(xs)
+        ? ys
+        : is_null(member(head(xs), ys))
+        ? pair(head(xs), insert_all(tail(xs), ys))
+        : error(head(xs), "multiple declarations of: ");
+}
+
+function local_names(stmt) {
+    if (is_sequence(stmt)) {
+        const stmts = sequence_statements(stmt);
+        return is_empty_sequence(stmts)
+            ? null
+            : insert_all(
+                local_names(first_statement(stmts)),
+                local_names(make_sequence(rest_statements(stmts)))
+            );
+    } else {
+        return is_constant_declaration(stmt)
+            ? list(constant_declaration_name(stmt))
+            : is_variable_declaration(stmt)
+            ? list(variable_declaration_name(stmt))
+            : null;
+    }
+}
+
+/* RETURN STATEMENTS */
+
+// functions return the value that results from
+// evaluating their expression
+
+function is_return_statement(stmt) {
+    return is_tagged_list(stmt, "return_statement");
+}
+function return_statement_expression(stmt) {
+    return head(tail(stmt));
+}
+
+function make_return_value(content) {
+    return list("return_value", content);
+}
+function is_return_value(value) {
+    return is_tagged_list(value, "return_value");
+}
+function return_value_content(value) {
+    return head(tail(value));
+}
+
+/* ASSIGNMENT */
+
+function is_assignment(stmt) {
+    return is_tagged_list(stmt, "assignment");
+}
+function assignment_name(stmt) {
+    return head(tail(head(tail(stmt))));
+}
+function assignment_value(stmt) {
+    return head(tail(tail(stmt)));
+}
+
+/* BLOCKS */
+
+// blocks are tagged with "block"
+function is_block(stmt) {
+    return is_tagged_list(stmt, "block");
+}
+function make_block(stmt) {
+    return list("block", stmt);
+}
+function block_body(stmt) {
+    return head(tail(stmt));
+}
+
+/* ENVIRONMENTS */
+
+// frames are pairs with a list of names as head
+// an a list of pairs as tail (values). Each value
+// pair has the proper value as head and a flag
+// as tail, which indicates whether assignment
+// is allowed for the corresponding name
+
+function make_frame(names, values) {
+    return pair(names, values);
+}
+function frame_names(frame) {
+    return head(frame);
+}
+function frame_values(frame) {
+    return tail(frame);
+}
+
+// The first frame in an environment is the
+// "innermost" frame. The tail operation
+// takes you to the "enclosing" environment
+
+function first_frame(env) {
+    return head(env);
+}
+function enclosing_environment(env) {
+    return tail(env);
+}
+function enclose_by(frame, env) {
+    return pair(frame, env);
+}
+function is_empty_environment(env) {
+    return is_null(env);
+}
+
+// set_name_value is used for let and const to give
+// the initial value to the name in the first
+// (innermost) frame of the given environment
+
+function set_name_value(name, val, env) {
+    function scan(names, vals) {
+        return is_null(names)
+            ? error("internal error: name not found")
+            : name === head(names)
+            ? set_head(head(vals), val)
+            : scan(tail(names), tail(vals));
+    }
+    const frame = first_frame(env);
+    return scan(frame_names(frame), frame_values(frame));
+}
+
+// name lookup proceeds from the innermost
+// frame and continues to look in enclosing
+// environments until the name is found
+
+function lookup_name_value(name, env) {
+    function env_loop(env) {
+        function scan(names, vals) {
+            return is_null(names)
+                ? env_loop(enclosing_environment(env))
+                : name === head(names)
+                ? head(head(vals))
+                : scan(tail(names), tail(vals));
+        }
+        if (is_empty_environment(env)) {
+            error(name, "Unbound name: ");
+        } else {
+            const frame = first_frame(env);
+            const value = scan(frame_names(frame), frame_values(frame));
+            if (value === no_value_yet) {
+                error(name, "Name used before declaration: ");
+            } else {
+                return value;
+            }
+        }
+    }
+    return env_loop(env);
+}
+
+// to assign a name to a new value in a specified environment,
+// we scan for the name, just as in lookup_name_value, and
+// change the corresponding value when we find it,
+// provided it is tagged as mutable
+
+function assign_name_value(name, val, env) {
+    function env_loop(env) {
+        function scan(names, vals) {
+            return is_null(names)
+                ? env_loop(enclosing_environment(env))
+                : name === head(names)
+                ? tail(head(vals))
+                ? set_head(head(vals), val)
+                : error("no assignment " + "to constants allowed")
+            : scan(tail(names), tail(vals));
+        }
+        if (is_empty_environment(env)) {
+            error(name, "Unbound name in assignment: ");
+        } else {
+            const frame = first_frame(env);
+            return scan(frame_names(frame), frame_values(frame));
+        }
+    }
+    return env_loop(env);
+}
+
+// applying a compound function to parameters will
+// lead to the creation of a new environment, with
+// respect to which the body of the function needs
+// to be evaluated
+// (also used for blocks)
+
+function extend_environment(names, vals, base_env) {
+    if (length(names) === length(vals)) {
+        return enclose_by(
+            make_frame(
+                names,
+                map((x) => pair(x, true), vals)
+            ),
+            base_env
+        );
+    } else if (length(names) &lt; length(vals)) {
+        error(
+            "Too many arguments supplied: " +
+                stringify(names) +
+                ", " +
+                stringify(vals)
+        );
+    } else {
+        error(
+            "Too few arguments supplied: " + stringify(names) + ", " + stringify(vals)
+        );
+    }
+}
+
+/* THE GLOBAL ENVIRONMENT */
+
+const the_empty_environment = null;
+
+// the minus operation is overloaded to
+// support both binary minus and unary minus
+
+function minus(x, y) {
+    if (is_number(x) &amp;&amp; is_number(y)) {
+        return x - y;
+    } else {
+        return -x;
+    }
+}
+
+// the global environment has bindings for all
+// primitive functions, including the operators
+
+const primitive_functions = list(
+    list("display", display),
+    list("error", error),
+    list("+", (x, y) => x + y),
+    list("-", (x, y) => minus(x, y)),
+    list("*", (x, y) => x * y),
+    list("/", (x, y) => x / y),
+    list("%", (x, y) => x % y),
+    list("===", (x, y) => x === y),
+    list("!==", (x, y) => x !== y),
+    list("&lt;", (x, y) => x &lt; y),
+    list("&lt;=", (x, y) => x &lt;= y),
+    list("&gt;", (x, y) => x &gt; y),
+    list("&gt;=", (x, y) => x &gt;= y),
+    list("!", (x) => !x)
+);
+
+// the global environment also has bindings for all
+// primitive non-function values, such as undefined and
+// math_PI
+
+const primitive_constants = list(
+    list("undefined", undefined),
+    list("math_PI", math_PI)
+);
+
+// setup_environment makes an environment that has
+// one single frame, and adds a binding of all names
+// listed as primitive_functions and primitive_values.
+// The values of primitive functions are "primitive"
+// objects, see line 281 how such functions are applied
+
+function setup_environment() {
+    const primitive_function_names = map((f) => head(f), primitive_functions);
+    const primitive_function_values = map(
+        (f) => make_primitive_function(head(tail(f))),
+        primitive_functions
+    );
+    const primitive_constant_names = map((f) => head(f), primitive_constants);
+    const primitive_constant_values = map(
+        (f) => head(tail(f)),
+        primitive_constants
+    );
+    return extend_environment(
+        append(primitive_function_names, primitive_constant_names),
+        append(primitive_function_values, primitive_constant_values),
+        the_empty_environment
+    );
+}
+
+function get_global_environment() {
+    return the_global_environment;
+}
+
+function user_print(object) {
+    return is_compound_function(object)
+        ? "function" +
+        stringify(function_parameters(object)) +
+        stringify(function_body(object)) +
+        "<environment>"
+        : object;
+}
+
+// END EVALUATOR SKELETON
+
+// Global registers
+let the_heads = [];
+let the_tails = [];
+let free = 0;
+
+const POINTER_TAG = 800;
+const NUMBER_TAG = 801;
+const STRING_TAG = 802;
+const NULL_TAG = -1;
+
+// Implementation is with arrays...
+function head_(n) {
+    return vector_ref(the_heads, n);
+}
+
+function tail_(n) {
+    return vector_ref(the_tails, n);
+}
+
+function vector_ref(xs, index) {
+    return xs[index];
+}
+
+function vector_set(xs, index, value) {
+    xs[index] = value;
+    display(xs);
+    return undefined;
+}
+
+function pair_(a, b) {
+    // perform(list(op("vector_set"), reg("the_heads"), reg("free"), a));
+    // perform(list(op("vector_set"), reg("the_tails"), reg("free"), b));
+    // assign("free", list(op("+"), reg("free"), constant(1)));
+    // display(is_number(a), "is_number");
+
+    const ret = free;
+    vector_set(the_heads, free, a);
+    vector_set(the_tails, free, b);
+
+    free = free + 1;
+    return ret;
+}
+
+function assoc(key, records) {
+    return is_null(records)
+        ? undefined
+        : equal(key, head(head(records)))
+        ? head(records)
+        : assoc(key, tail(records));
+}
+
+function get_contents(register) {
+    return register("get");
+}
+
+function set_contents(register, value) {
+    return register("set")(value);
+}
+
+function op(name) {
+    return list("op", name);
+}
+
+function reg(name) {
+    return list("reg", name);
+}
+
+function label(name) {
+    return list("label", name);
+}
+
+function constant(value) {
+    return list("constant", value);
+}
+
+function branch(label) {
+    return list("branch", label);
+}
+
+function assign(register_name, source) {
+    const a = append(list("assign", register_name), source);
+    return a;
+}
+
+function perform(args) {
+    const a = append(list("perform"), args);
+    return a;
+}
+
+// Made an n-ary function helper...
+function nary_function(f) {
+    // f is n-ary
+    return (arg_list) => apply_in_underlying_javascript(f, arg_list);
+}
+
+function save(value) {
+    return list("save", value);
+}
+
+function restore(value) {
+    return list("restore", value);
+}
+
+function go_to(label) {
+    return list("go_to", label);
+}
+
+function test(op, lhs) {
+    return list("test", op, lhs, constant(true));
+}
+
+function binary_function(f) {
+    // f is binary
+    return (arg_list) =>
+        length(arg_list) === 2
+        ? apply_in_underlying_javascript(f, arg_list)
+        : error(
+            arg_list,
+            "Incorrect number of arguments passed to binary function "
+        );
+}
+
+function make_machine(register_names, ops, controller_text) {
+    const machine = make_new_machine();
+
+    map((reg_name) => machine("allocate_register")(reg_name), register_names);
+    machine("install_operations")(ops);
+    machine("install_instruction_sequence")(assemble(controller_text, machine));
+
+    return machine;
+}
+
+function make_register(name) {
+    let contents = "*unassigned*";
+
+    function dispatch(message) {
+        if (message === "get") {
+            return contents;
+        } else {
+            if (message === "set") {
+                return (value) => {
+                    contents = value;
+                };
+            } else {
+                error(message, "Unknown request: REGISTER");
+            }
+        }
+    }
+
+    return dispatch;
+}
+
+function debug(reg) {
+    display(reg);
+}
+
+function make_stack() {
+    let stack = null;
+
+    function push(x) {
+        stack = pair(x, stack);
+        return "done";
+    }
+
+    function pop() {
+        if (is_null(stack)) {
+            error("Empty stack: POP");
+        } else {
+            const top = head(stack);
+            stack = tail(stack);
+            return top;
+        }
+    }
+
+    function initialize() {
+        stack = null;
+        return "done";
+    }
+
+    function dispatch(message) {
+        return message === "push"
+            ? push
+            : message === "pop"
+            ? pop()
+            : message === "initialize"
+            ? initialize()
+            : error("Unknown request: STACK", message);
+    }
+
+    return dispatch;
+}
+
+function pop(stack) {
+    return stack("pop");
+}
+
+function push(stack, value) {
+    return stack("push")(value);
+}
+
+function make_new_machine() {
+    const pc = make_register("pc");
+    const flag = make_register("flag");
+    const stack = make_stack();
+    let the_instruction_sequence = null;
+    let the_ops = list(list("initialize_stack", () => stack("initialize")));
+    let register_table = list(list("pc", pc), list("flag", flag));
+
+    function allocate_register(name) {
+        if (assoc(name, register_table) === undefined) {
+            register_table = pair(list(name, make_register(name)), register_table);
+        } else {
+            error(name, "Multiply defined register: ");
+        }
+
+        return "register_allocated";
+    }
+
+    function lookup_register(name) {
+        const val = assoc(name, register_table);
+
+        return val === undefined
+            ? error(name, "Unknown register:")
+            : head(tail(val));
+    }
+
+    function execute() {
+        const insts = get_contents(pc);
+
+        if (is_null(insts)) {
+            return "done";
+        } else {
+            const proc = instruction_execution_proc(head(insts));
+            proc();
+            return execute();
+        }
+    }
+
+    function dispatch(message) {
+        return message === "start"
+            ? () => {
+                set_contents(pc, the_instruction_sequence);
+                return execute();
+            }
+        : message === "install_instruction_sequence"
+            ? (seq) => {
+                the_instruction_sequence = seq;
+            }
+        : message === "allocate_register"
+            ? allocate_register
+            : message === "get_register"
+            ? lookup_register
+            : message === "install_operations"
+            ? (ops) => {
+                the_ops = append(the_ops, ops);
+            }
+        : message === "stack"
+            ? stack
+            : message === "operations"
+            ? the_ops
+            : error(message, "Unknown request: MACHINE");
+    }
+
+    return dispatch;
+}
+
+function start(machine) {
+    return machine("start")();
+}
+
+function get_register_contents(machine, register_name) {
+    return get_contents(get_register(machine, register_name));
+}
+
+function set_register_contents(machine, register_name, value) {
+    set_contents(get_register(machine, register_name), value);
+    return "done";
+}
+
+function get_register(machine, reg_name) {
+    return machine("get_register")(reg_name);
+}
+
+function assemble(controller_text, machine) {
+    function receive(insts, labels) {
+        update_insts(insts, labels, machine);
+        return insts;
+    }
+
+    return extract_labels(controller_text, receive);
+}
+
+function extract_labels(text, receive) {
+    function helper(insts, labels) {
+        /// FIXME: rename to something useful
+        const next_inst = head(text);
+
+        return is_string(next_inst)
+            ? receive(insts, pair(make_label_entry(next_inst, insts), labels))
+            : receive(pair(make_instruction(next_inst), insts), labels);
+    }
+
+    return text === undefined || is_null(text)
+        ? receive(null, null)
+        : extract_labels(tail(text), helper);
+}
+
+function update_insts(insts, labels, machine) {
+    const pc = get_register(machine, "pc");
+    const flag = get_register(machine, "flag");
+    const stack = machine("stack");
+    const ops = machine("operations");
+
+    const set_iep = set_instruction_execution_proc;
+    const make_ep = make_execution_procedure;
+    return map(
+        (i) =>
+            set_iep(
+                i,
+                make_ep(instruction_text(i), labels, machine, pc, flag, stack, ops)
+            ),
+        insts
+    );
+}
+
+function make_instruction(text) {
+    return pair(text, null);
+}
+
+function instruction_text(inst) {
+    return head(inst);
+}
+
+function instruction_execution_proc(inst) {
+    return tail(inst);
+}
+
+function set_instruction_execution_proc(inst, proc) {
+    set_tail(inst, proc);
+}
+
+function make_label_entry(label_name, insts) {
+    return pair(label_name, insts);
+}
+
+function lookup_label(labels, label_name) {
+    const val = assoc(label_name, labels);
+
+    return val === undefined
+        ? error(label_name, "Undefined label: ASSEMBLE")
+        : tail(val);
+}
+
+function make_execution_procedure(inst, labels, machine, pc, flag, stack, ops) {
+    const x = head(inst);
+
+    return x === "assign"
+        ? make_assign(inst, machine, labels, ops, pc)
+        : x === "test"
+        ? make_test(inst, machine, labels, ops, flag, pc)
+        : x === "branch"
+        ? make_branch(inst, machine, labels, flag, pc)
+        : x === "go_to"
+        ? make_goto(inst, machine, labels, pc)
+        : x === "save"
+        ? make_save(inst, machine, stack, pc)
+        : x === "restore"
+        ? make_restore(inst, machine, stack, pc)
+        : x === "perform"
+        ? make_perform(inst, machine, labels, ops, pc)
+        : error(inst, "Unknown instruction type: ASSEMBLE");
+}
+
+function make_assign(inst, machine, labels, operations, pc) {
+    const target = get_register(machine, assign_reg_name(inst));
+    const value_exp = assign_value_exp(inst);
+
+    // FIX FOR LABEL
+    const value_proc = is_operation_exp(value_exp)
+          ? make_operation_exp(value_exp, machine, labels, operations)
+          : // fix for label...
+          is_label_exp(value_exp)
+          ? make_primitive_exp(value_exp, machine, labels)
+          : make_primitive_exp(head(value_exp), machine, labels);
+
+    function perform_make_assign() {
+        set_contents(target, value_proc());
+        advance_pc(pc);
+    }
+
+    return perform_make_assign;
+}
+
+function assign_reg_name(assign_instruction) {
+    return head(tail(assign_instruction));
+}
+
+function assign_value_exp(assign_instruction) {
+    return tail(tail(assign_instruction));
+}
+
+function advance_pc(pc) {
+    set_contents(pc, tail(get_contents(pc)));
+}
+
+function make_test(inst, machine, labels, operations, flag, pc) {
+    const condition = test_condition(inst);
+
+    if (is_operation_exp(condition)) {
+        const condition_proc = make_operation_exp(
+            condition,
+            machine,
+            labels,
+            operations
+        );
+
+        function perform_make_test() {
+            set_contents(flag, condition_proc());
+            advance_pc(pc);
+        }
+
+        return perform_make_test;
+    } else {
+        error(inst, "Bad TEST instruction: ASSEMBLE");
+    }
+}
+
+function test_condition(test_instruction) {
+    return tail(test_instruction);
+}
+
+function make_branch(inst, machine, labels, flag, pc) {
+    const dest = branch_dest(inst);
+
+    if (is_label_exp(dest)) {
+        const insts = lookup_label(labels, label_exp_label(dest));
+
+        function perform_make_branch() {
+            if (get_contents(flag)) {
+                set_contents(pc, insts);
+            } else {
+                advance_pc(pc);
+            }
+        }
+
+        return perform_make_branch;
+    } else if (is_register_exp(dest)) {
+        const reg = get_register(machine, register_exp_reg(dest));
+
+        function perform_make_branch() {
+            if (get_contents(flag)) {
+                set_contents(pc, get_contents(reg));
+            } else {
+                advance_pc(pc);
+            }
+        }
+
+        return perform_make_branch;
+    } else {
+        error(inst, "Bad BRANCH instruction: ASSEMBLE");
+    }
+}
+
+function branch_dest(branch_instruction) {
+    return head(tail(branch_instruction));
+}
+
+function make_goto(inst, machine, labels, pc) {
+    const dest = goto_dest(inst);
+
+    if (is_label_exp(dest)) {
+        const insts = lookup_label(labels, label_exp_label(dest));
+        return () => set_contents(pc, insts);
+    } else if (is_register_exp(dest)) {
+        const reg = get_register(machine, register_exp_reg(dest));
+        return () => set_contents(pc, get_contents(reg));
+    } else {
+        error(inst, "Bad GOTO instruction: ASSEMBLE");
+    }
+}
+
+function goto_dest(goto_instruction) {
+    return head(tail(goto_instruction));
+}
+
+function make_save(inst, machine, stack, pc) {
+    const reg = get_register(machine, stack_inst_reg_name(inst));
+
+    function perform_make_save() {
+        push(stack, get_contents(reg));
+        advance_pc(pc);
+    }
+
+    return perform_make_save;
+}
+
+function make_restore(inst, machine, stack, pc) {
+    const reg = get_register(machine, stack_inst_reg_name(inst));
+
+    function perform_make_restore() {
+        set_contents(reg, pop(stack));
+        advance_pc(pc);
+    }
+
+    return perform_make_restore;
+}
+
+function stack_inst_reg_name(stack_instruction) {
+    return head(tail(stack_instruction));
+}
+
+function make_perform(inst, machine, labels, operations, pc) {
+    const action = perform_action(inst);
+
+    if (is_operation_exp(action)) {
+        const action_proc = make_operation_exp(action, machine, labels, operations);
+        return () => {
+            action_proc();
+            advance_pc(pc);
+        };
+    } else {
+        error(inst, "Bad PERFORM instruction: ASSEMBLE");
+    }
+}
+
+function perform_action(inst) {
+    return tail(inst);
+}
+
+function make_primitive_exp(exp, machine, labels) {
+    if (is_constant_exp(exp)) {
+        const c = constant_exp_value(exp);
+        return () => c;
+    } else if (is_label_exp(exp)) {
+        const insts = lookup_label(labels, label_exp_label(exp));
+        return () => insts;
+    } else if (is_register_exp(exp)) {
+        const r = get_register(machine, register_exp_reg(exp));
+        return () => get_contents(r);
+    } else {
+        error(exp, "Unknown expression type: ASSEMBLE");
+    }
+}
+
+function is_register_exp(exp) {
+    return is_tagged_list(exp, "reg");
+}
+
+function register_exp_reg(exp) {
+    return head(tail(exp));
+}
+
+function is_constant_exp(exp) {
+    return is_tagged_list(exp, "constant");
+}
+
+function constant_exp_value(exp) {
+    return head(tail(exp));
+}
+
+function is_label_exp(exp) {
+    return is_tagged_list(exp, "label");
+}
+
+function label_exp_label(exp) {
+    return head(tail(exp));
+}
+
+function make_operation_exp(exp, machine, labels, operations) {
+    const op = lookup_prim(operation_exp_op(exp), operations);
+    const aprocs = map(
+        (e) => make_primitive_exp(e, machine, labels),
+        operation_exp_operands(exp)
+    );
+
+    function perform_make_operation_exp() {
+        return op(map((p) => p(), aprocs));
+    }
+
+    return perform_make_operation_exp;
+}
+
+function is_operation_exp(exp) {
+    return is_pair(exp) &amp;&amp; is_tagged_list(head(exp), "op");
+}
+
+function operation_exp_op(operation_exp) {
+    return head(tail(head(operation_exp)));
+}
+
+function operation_exp_operands(operation_exp) {
+    return tail(operation_exp);
+}
+
+function lookup_prim(symbol, operations) {
+    const val = assoc(symbol, operations);
+
+    return val === undefined
+        ? error(symbol, "Unknown operation: ASSEMBLE")
+        : head(tail(val));
+}
+
+function eceval() {
+    return make_machine(
+        list(
+            "exp",
+            "env",
+            "val",
+            "continue",
+            "fun",
+            "argl",
+            "unev",
+            "temp" // FIXME: TOBIAS -- not mentioned in 5.4
+        ),
+        list(
+            // basic functions
+            list(
+                "rem",
+                binary_function((a, b) => a % b)
+            ),
+            list(
+                "=",
+                binary_function((a, b) => a === b)
+            ),
+            list(
+                "+",
+                binary_function((a, b) => a + b)
+            ),
+            list(
+                "===",
+                binary_function((a, b) => a === b)
+            ),
+            // operands
+            list("operands", nary_function(operands)),
+            list("operator", nary_function(operator)),
+            list("has_no_operands", nary_function(no_operands)),
+            list("first_operand", nary_function(first_operand)),
+            list(
+                "is_last_operand",
+                nary_function((a) => is_null(tail(a)))
+            ),
+            list("rest_operands", nary_function(rest_operands)),
+
+            //arg
+            list(
+                "empty_arglist",
+                nary_function((_) => list())
+            ),
+            list(
+                "adjoin_arg",
+                nary_function((val, argl) => append(argl, list(val)))
+            ),
+
+            // exp (sequence)
+            list("first_statement", nary_function(first_statement)),
+            list("rest_statements", nary_function(rest_statements)),
+            list("is_last_statement", nary_function(is_last_statement)),
+            list("sequence_statements", nary_function(sequence_statements)),
+
+            // eval functions from meta-circular evaluator
+            list("is_self_evaluating", nary_function(is_self_evaluating)),
+            list("is_name", nary_function(is_name)),
+            list("name_of_name", nary_function(name_of_name)),
+            list(
+                "all_names_of_names",
+                nary_function((names) => map(name_of_name, names))
+            ),
+            list("is_assignment", nary_function(is_assignment)),
+            list("assignment_name", nary_function(assignment_name)),
+            list("assignment_value", nary_function(assignment_value)),
+            list("assign_name_value", nary_function(assign_name_value)),
+            list("is_constant_declaration", nary_function(is_constant_declaration)),
+            list(
+                "constant_declaration_name",
+                nary_function(constant_declaration_name)
+            ),
+            list(
+                "constant_declaration_value",
+                nary_function(constant_declaration_value)
+            ),
+            list("is_variable_declaration", nary_function(is_variable_declaration)),
+            list(
+                "variable_declaration_name",
+                nary_function(variable_declaration_name)
+            ),
+            list(
+                "variable_declaration_value",
+                nary_function(variable_declaration_value)
+            ),
+            list("declare_value", nary_function(set_name_value)),
+            list("is_function_definition", nary_function(is_function_definition)),
+            list(
+                "function_definition_parameters",
+                nary_function(function_definition_parameters)
+            ),
+            list("function_definition_body", nary_function(function_definition_body)),
+            list("is_return_statement", nary_function(is_return_statement)),
+            list(
+                "is_conditional_expression",
+                nary_function(is_conditional_expression)
+            ),
+            list("conditional_pred", nary_function(cond_expr_pred)),
+            list("conditional_cons", nary_function(cond_expr_cons)),
+            list("conditional_alt", nary_function(cond_expr_alt)),
+
+            list("is_sequence", nary_function(is_sequence)),
+            list("make_sequence", nary_function(make_sequence)),
+            list("is_block", nary_function(is_block)),
+            list("block_body", nary_function(block_body)),
+            list("local_names", nary_function(local_names)),
+            list(
+                "get_temp_block_values",
+                nary_function((locals) => map((x) => no_value_yet, locals))
+            ),
+            list("is_application", nary_function(is_application)),
+            list("is_primitive_function", nary_function(is_primitive_function)),
+            list("apply_primitive_function", nary_function(apply_primitive_function)),
+            list("is_compound_function", nary_function(is_compound_function)),
+            list("function_parameters", nary_function(function_parameters)),
+            list("function_environment", nary_function(function_environment)),
+            list("function_body", nary_function(function_body)),
+            list("insert_all", nary_function(insert_all)),
+            list("extend_environment", nary_function(extend_environment)),
+            list("make_compound_function", nary_function(make_compound_function)),
+
+            list(
+                "lookup_name_value",
+                nary_function((stmt, env) => lookup_name_value(name_of_name(stmt), env))
+            ),
+            list("get_global_environment", nary_function(get_global_environment)),
+
+            // generic helpers
+            list("is_true", nary_function(is_true)),
+            list("is_null", nary_function(is_null)),
+            list(
+                "is_pair",
+                nary_function((a) => is_pair(a))
+            ),
+            list(
+                "is_number",
+                nary_function((a) => is_number(a))
+            ),
+            list(
+                "append",
+                nary_function((xs, ys) => append(xs, ys))
+            ),
+
+            list("vector_ref", binary_function(vector_ref)),
+            list("vector_set", nary_function(vector_set)),
+            list("pair", nary_function(pair_)),
+
+            list("user_print", nary_function(user_print)),
+            list("display", nary_function(display))
+        ),
+        list(
+            assign("continue", label("evaluator_done")),
+            assign("env", list(op("get_global_environment"))),
+            "ev_begin",
+
+            // This corresponds to the 'evaluate' function
+            // The workhorse of our evaluator is the evaluate function.
+            // It dispatches on the kind of statement at hand, and
+            // invokes the appropriate implementations of their
+            // evaluation process, as described above, always using
+            // a current environment
+            // See the source code at bottom of file for refrence
+            "eval_dispatch",
+            test(op("is_self_evaluating"), reg("exp")), // <-- TOBIAS need to make "true" default because not in the book
+            branch(label("ev_self_eval")),
+            test(op("is_name"), reg("exp")),
+            branch(label("ev_name")),
+
+            // for now, treat let/const the same
+            test(op("is_variable_declaration"), reg("exp")),
+            branch(label("ev_variable_declaration")),
+            test(op("is_constant_declaration"), reg("exp")),
+            branch(label("ev_constant_declaration")),
+            test(op("is_assignment"), reg("exp")),
+            branch(label("ev_assignment")),
+
+            test(op("is_conditional_expression"), reg("exp")),
+            branch(label("ev_if")),
+            test(op("is_function_definition"), reg("exp")),
+            branch(label("ev_lambda")),
+            test(op("is_sequence"), reg("exp")),
+            branch(label("ev_seq")),
+            test(op("is_block"), reg("exp")),
+            branch(label("ev_block")),
+            test(op("is_application"), reg("exp")),
+            branch(label("ev_application")),
+            go_to(label("unknown_expression_type")),
+
+            "ev_self_eval",
+            assign("val", list(reg("exp"))),
+            go_to(reg("continue")),
+
+            "ev_name",
+            assign("val", list(op("lookup_name_value"), reg("exp"), reg("env"))),
+            go_to(reg("continue")),
+
+            "ev_lambda",
+            assign("unev", list(op("function_definition_parameters"), reg("exp"))),
+            assign("exp", list(op("function_definition_body"), reg("exp"))),
+            assign(
+                "val",
+                list(op("make_compound_function"), reg("unev"), reg("exp"), reg("env"))
+            ),
+            go_to(reg("continue")),
+
+            "ev_application",
+            save("continue"),
+            save("env"),
+            assign("unev", list(op("operands"), reg("exp"))),
+            save("unev"),
+            assign("exp", list(op("operator"), reg("exp"))),
+            assign("continue", label("ev_appl_did_operator")),
+            go_to(label("eval_dispatch")),
+
+            "ev_appl_did_operator",
+            restore("unev"), // the operands
+            restore("env"),
+            assign("argl", list(op("empty_arglist"))),
+            assign("fun", list(reg("val"))), // the operator
+            test(op("has_no_operands"), reg("unev")),
+            branch(label("apply_dispatch")),
+            save("fun"),
+
+            "ev_appl_operand_loop",
+            save("argl"),
+            assign("exp", list(op("first_operand"), reg("unev"))),
+            test(op("is_last_operand"), reg("unev")),
+            branch(label("ev_appl_last_arg")),
+            save("env"),
+            save("unev"),
+            assign("continue", label("ev_appl_accumulate_arg")),
+            go_to(label("eval_dispatch")),
+
+            "ev_appl_accumulate_arg",
+            restore("unev"),
+            restore("env"),
+            restore("argl"),
+            assign("argl", list(op("adjoin_arg"), reg("val"), reg("argl"))),
+            assign("unev", list(op("rest_operands"), reg("unev"))),
+            go_to(label("ev_appl_operand_loop")),
+
+            "ev_appl_last_arg",
+            assign("continue", label("ev_appl_accum_last_arg")),
+            go_to(label("eval_dispatch")),
+
+            "ev_appl_accum_last_arg",
+            restore("argl"),
+            assign("argl", list(op("adjoin_arg"), reg("val"), reg("argl"))),
+            restore("fun"),
+            go_to(label("apply_dispatch")),
+
+            // function application needs to distinguish between
+            // primitive functions (which are evaluated using the
+            // underlying JavaScript), and compound functions.
+            // An application of the latter needs to evaluate the
+            // body of the function value with respect to an
+            // environment that results from extending the function
+            // object's environment by a binding of the function
+            // parameters to the arguments and of local names to
+            // the special value no_value_yet
+
+            // function apply(fun, args) {
+            //   if (is_primitive_function(fun)) {
+            //     return apply_primitive_function(fun, args);
+            //   } else if (is_compound_function(fun)) {
+            //     const body = function_body(fun);
+            //     const locals = local_names(body);
+            //     const names = insert_all(function_parameters(fun), locals);
+            //     const temp_values = map((x) => no_value_yet, locals);
+            //     const values = append(args, temp_values);
+            //     const result = evaluate(
+            //       body,
+            //       extend_environment(names, values, function_environment(fun))
+            //     );
+            //     if (is_return_value(result)) {
+            //       return return_value_content(result);
+            //     } else {
+            //       return undefined;
+            //     }
+            //   } else {
+            //     error(fun, "Unknown function type in apply");
+            //   }
+            // }
+            "apply_dispatch",
+            test(op("is_primitive_function"), reg("fun")),
+            branch(label("primitive_apply")),
+            test(op("is_compound_function"), reg("fun")),
+            branch(label("compound_apply")),
+            go_to(label("unknown_procedure_type")),
+
+            "primitive_apply",
+            assign(
+                "val",
+                list(op("apply_primitive_function"), reg("fun"), reg("argl"))
+            ),
+            restore("continue"),
+            go_to(reg("continue")),
+
+            "compound_apply",
+            assign("unev", list(op("function_parameters"), reg("fun"))), // params
+            // A QUICK HACK HERE, UNSURE WHY IT'S NEEDED
+            assign("unev", list(op("all_names_of_names"), reg("unev"))), // params destructured
+
+            assign("temp", list(op("function_body"), reg("fun"))), // body
+            assign("temp", list(op("local_names"), reg("unev"))), // locals
+
+            assign("unev", list(op("insert_all"), reg("unev"), reg("temp"))), //names
+            assign("temp", list(op("get_temp_block_values"), reg("temp"))), // temp_values
+
+            assign("temp", list(op("append"), reg("argl"), reg("temp"))), // values
+            assign("env", list(op("function_environment"), reg("fun"))),
+
+            assign(
+                "env",
+                list(op("extend_environment"), reg("unev"), reg("temp"), reg("env"))
+            ),
+            assign("unev", list(op("function_body"), reg("fun"))),
+            go_to(label("ev_sequence")),
+
+            // to evaluate a sequence, we need to evaluate
+            // its statements one after the other, and return
+            // the value of the last statement.
+            // An exception to this rule is when a return
+            // statement is encountered. In that case, the
+            // remaining statements are ignored and the
+            // return value is the value of the sequence.
+
+            // function eval_sequence(stmts, env) {
+            //   if (is_empty_sequence(stmts)) {
+            //     return undefined;
+            //   } else if (is_last_statement(stmts)) {
+            //     return evaluate(first_statement(stmts), env);
+            //   } else {
+            //     const first_stmt_value = evaluate(first_statement(stmts), env);
+            //     if (is_return_value(first_stmt_value)) {
+            //       return first_stmt_value;
+            //     } else {
+            //       return eval_sequence(rest_statements(stmts), env);
+            //     }
+            //   }
+            // }
+            "ev_seq",
+            save("continue"),
+            assign("unev", list(op("sequence_statements"), reg("exp"))),
+
+            "ev_sequence",
+            assign("exp", list(op("first_statement"), reg("unev"))),
+            test(op("is_last_statement"), reg("unev")),
+            branch(label("ev_sequence_last_exp")),
+            save("unev"),
+            save("env"),
+            assign("continue", label("ev_sequence_continue")),
+            go_to(label("eval_dispatch")),
+
+            "ev_sequence_continue",
+            restore("env"),
+            restore("unev"),
+            assign("unev", list(op("rest_statements"), reg("unev"))),
+            go_to(label("ev_sequence")),
+
+            "ev_sequence_last_exp",
+            restore("continue"),
+            go_to(label("eval_dispatch")),
+
+            // evaluation of blocks evaluates the body of the block
+            // with respect to the current environment extended by
+            // a binding of all local names to the special value
+            // no_value_yet
+
+            // function eval_block(stmt, env) {
+            //   const body = block_body(stmt);
+            //   const locals = local_names(body);
+            //   const temp_values = map((x) => no_value_yet, locals);
+            //   return evaluate(body, extend_environment(locals, temp_values, env));
+            // }
+            "ev_block",
+            save("continue"),
+            assign("exp", list(op("block_body"), reg("exp"))),
+            assign("val", list(op("local_names"), reg("exp"))),
+            assign("temp", list(op("get_temp_block_values"), reg("val"))),
+            assign(
+                "env",
+                list(op("extend_environment"), reg("val"), reg("temp"), reg("env"))
+            ),
+            go_to(label("eval_dispatch")),
+
+            // the meta-circular evaluation of conditional expressions
+            // evaluates the predicate and then the appropriate
+            // branch, depending on whether the predicate evaluates to
+            // true or not
+
+            // function eval_conditional_expression(stmt, env) {
+            //   return is_true(evaluate(cond_expr_pred(stmt), env))
+            //     ? evaluate(cond_expr_cons(stmt), env)
+            //     : evaluate(cond_expr_alt(stmt), env);
+            // }
+            "ev_if",
+            save("exp"), // save expression for later
+            save("env"),
+            save("continue"),
+            assign("continue", label("ev_if_decide")),
+            assign("exp", list(op("conditional_pred"), reg("exp"))),
+            go_to(label("eval_dispatch")), // evaluate the predicate
+
+            "ev_if_decide",
+            restore("continue"),
+            restore("env"),
+            restore("exp"),
+            test(op("is_true"), reg("val")),
+            branch(label("ev_if_consequent")),
+
+            "ev_if_alternative",
+            assign("exp", list(op("conditional_alt"), reg("exp"))),
+            go_to(label("eval_dispatch")),
+
+            "ev_if_consequent",
+            assign("exp", list(op("conditional_cons"), reg("exp"))),
+            go_to(label("eval_dispatch")),
+
+            // function eval_assignment(stmt, env) {
+            //   const value = evaluate(assignment_value(stmt), env);
+            //   assign_name_value(assignment_name(stmt), value, env);
+            //   return value;
+            // }
+            "ev_assignment",
+            assign("unev", list(op("assignment_name"), reg("exp"))),
+            save("unev"), // save variable for later
+            assign("exp", list(op("assignment_value"), reg("exp"))),
+            save("env"),
+            save("continue"),
+            assign("continue", label("ev_assignment_1")),
+            go_to(label("eval_dispatch")), // evaluate the assignment value
+
+            "ev_assignment_1",
+            restore("continue"),
+            restore("env"),
+            restore("unev"),
+            perform(
+                list(op("assign_name_value"), reg("unev"), reg("val"), reg("env"))
+            ),
+            assign("val", list(constant("ok"))),
+            go_to(reg("continue")),
+
+            // evaluation of a constant declaration evaluates
+            // the right-hand expression and binds the
+            // name to the resulting value in the
+            // first (innermost) frame
+
+            // function eval_constant_declaration(stmt, env) {
+            //   set_name_value(
+            //     constant_declaration_name(stmt),
+            //     evaluate(constant_declaration_value(stmt), env),
+            //     env
+            //   );
+            // }
+            "ev_variable_declaration",
+            assign("unev", list(op("variable_declaration_name"), reg("exp"))),
+            save("unev"), // save variable for later
+            assign("exp", list(op("variable_declaration_value"), reg("exp"))),
+            save("env"),
+            save("continue"),
+            assign("continue", label("ev_variable_declaration_1")),
+            go_to(label("eval_dispatch")), // evaluate the declaration value
+
+            "ev_variable_declaration_1",
+            restore("continue"),
+            restore("env"),
+            restore("unev"),
+            perform(list(op("declare_value"), reg("unev"), reg("val"), reg("env"))),
+            assign("val", list(constant("ok"))),
+            go_to(reg("continue")),
+
+            "ev_constant_declaration",
+            assign("unev", list(op("constant_declaration_name"), reg("exp"))),
+            save("unev"), // save constant for later
+            assign("exp", list(op("constant_declaration_value"), reg("exp"))),
+            save("env"),
+            save("continue"),
+            assign("continue", label("ev_constant_declaration_1")),
+            go_to(label("eval_dispatch")), // evaluate the declaration value
+
+            "ev_constant_declaration_1",
+            restore("continue"),
+            restore("env"),
+            restore("unev"),
+            perform(list(op("declare_value"), reg("unev"), reg("val"), reg("env"))),
+            assign("val", list(constant("ok"))),
+            go_to(reg("continue")),
+
+            // Error handling
+            "unknown_expression_type",
+            assign("val", list(constant("unknown_expression_type_error"))),
+            go_to(label("signal_error")),
+
+            "unknown_procedure_type",
+            restore("continue"), /// clean up stack (from apply_dispatch)
+            assign("val", list(constant("unknown_procedure_type_error"))),
+            go_to(label("signal_error")),
+
+            "signal_error",
+            perform(list(op("user_print"), reg("val"))),
+            go_to(label("evaluator_done")),
+
+            "evaluator_done"
+        )
+    );
+}
+
+const m = eceval();
+set_register_contents(m, "exp", "1;");
+
+function set_program_to_run(str) {
+    const parsed = parse(str);
+    // wrap program in block to create
+    // program environment
+    const program_block = make_block(parsed);
+
+    set_register_contents(m, "exp", program_block);
+}
+
+set_program_to_run(
+    "function factorial(n) { return n === 1 ? 1 : n * factorial(n - 1);} factorial(4);"
+);
+
+const the_global_environment = setup_environment();
+
+start(m);
+
+get_register_contents(m, "val");
+      
+    </JAVASCRIPT_RUN>
     <JAVASCRIPT>
 const the_global_environment = setup_environment();
 
@@ -291,11 +1989,11 @@ start(eceval);
       ^$\ldots$^ ; same as before
     </SCHEME>
     <JAVASCRIPT>
-      <!--  \indcode*{print-result}[monitored-stack version] -->
-      "print_result",
-          perform(op("print_stack_statistics")), // added instruction
-          perform(op("announce_output"), const("/// EC-Eval value:")),
-          /* ... same as before ... */
+<!--  \indcode*{print-result}[monitored-stack version] -->
+"print_result",
+    perform(op("print_stack_statistics")), // added instruction
+    perform(op("announce_output"), constant("/// EC-Eval value:")),
+    /* ... same as before ... */
     </JAVASCRIPT>
   </SNIPPET>
       </TEXT>
@@ -370,7 +2068,7 @@ factorial(5);
     <JAVASCRIPT>
 function factorial(n) {
     function iter(product, counter, max_count) {
-        return counter > max_count
+        return counter &gt; max_count
                ? product
                : fact_iter(counter * product,
                            counter + 1,
@@ -527,7 +2225,7 @@ function fib(n) {
       access an unbound variable, could be caught by changing the lookup
       operation to make it return a distinguished condition code, which cannot
       be a possible value of any user variable.  The evaluator can test
-      for this condition code and then do what is necessary to go to <SCHEMEINLINE>signal-error</SCHEMEINLINE>.  Find all of the places in the evaluator where such a
+      for this condition code and then do what is necessary to go to <SPLITINLINE><SCHEME><SCHEMEINLINE>signal-error</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>signal_error</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>.  Find all of the places in the evaluator where such a
       change is necessary and fix them.  This is lots of work.
     </LI>
     <LI>
@@ -543,8 +2241,8 @@ function fib(n) {
       for this in our register-machine simulator by making each primitive
       <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
       check for applicability and returning an appropriate distinguished
-      condition code on failure. Then the <SCHEMEINLINE>primitive-apply</SCHEMEINLINE> code in the
-      evaluator can check for the condition code and go to <SCHEMEINLINE>signal-error</SCHEMEINLINE> if necessary.  Build this structure and make it work.
+      condition code on failure. Then the <SPLITINLINE><SCHEME><SCHEMEINLINE>primitive-apply</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>primitive_apply</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> code in the
+      evaluator can check for the condition code and go to <SPLITINLINE><SCHEME><SCHEMEINLINE>signal-error</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>signal_error</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> if necessary.  Build this structure and make it work.
       This is a major project.
     </LI>
   </OL>
diff --git a/xml/chapter5/section5/subsection1.xml b/xml/chapter5/section5/subsection1.xml
index 123fa9ce3..155c099bb 100644
--- a/xml/chapter5/section5/subsection1.xml
+++ b/xml/chapter5/section5/subsection1.xml
@@ -85,7 +85,7 @@
     <JAVASCRIPT>
       <!--  \indcode*{compile} -->
 function compile(exp, target, linkage) {
-    return is_self-evaluating(exp)
+    return is_self_evaluating(exp)
         ? compile_self_evaluating(exp, target, linkage)
         : is_quoted(exp)
         ? compile_quoted(exp, target, linkage)
diff --git a/xml/chapter5/section5/subsection2.xml b/xml/chapter5/section5/subsection2.xml
index dfae3d71c..025b628b0 100644
--- a/xml/chapter5/section5/subsection2.xml
+++ b/xml/chapter5/section5/subsection2.xml
@@ -345,7 +345,7 @@ function compile_definition(exp, target, linkage) {
 
         function new_label_number() {
             label_counter = label_counter + 1;
-            return label-counter;
+            return label_counter;
         }
 
         <INDEX>character strings<SUBINDEX>primitive functions for</SUBINDEX></INDEX>
diff --git a/xml/chapter5/section5/subsection3.xml b/xml/chapter5/section5/subsection3.xml
index 999c8ae8e..ae007b2ff 100644
--- a/xml/chapter5/section5/subsection3.xml
+++ b/xml/chapter5/section5/subsection3.xml
@@ -250,7 +250,7 @@ function code_to_get_rest_args(operand_codes) {
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   in the
   meta-circular evaluator of section<SPACE/><REF NAME="sec:core-of-evaluator"/> or the
-  <SCHEMEINLINE>apply-dispatch</SCHEMEINLINE> entry point in the explicit-control evaluator of
+  <SPLITINLINE><SCHEME><SCHEMEINLINE>apply-dispatch</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>apply_dispatch</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> entry point in the explicit-control evaluator of
   section<SPACE/><REF NAME="sec:procedure-application"/>.  It checks whether the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   to be applied is a primitive
@@ -278,11 +278,11 @@ function code_to_get_rest_args(operand_codes) {
       after-call
     </SCHEME>
     <JAVASCRIPT>
-  test(op("primitive-procedure"), reg("proc")),
+  test(op("primitive_procedure"), reg("proc")),
   branch(label("primitive_branch")),
-"compiled-branch",
+"compiled_branch",
   $\langle \textit{code to apply compiled procedure with given target and appropriate linkage} \rangle$
-"primitive-branch",
+"primitive_branch",
   assign($\langle\textit{target}\rangle$,
          list(op("apply_primitive_procedure"),
          reg("proc"),
@@ -332,9 +332,9 @@ $\langle\textit{linkage}\rangle$
     </SCHEME>
     <JAVASCRIPT>
 function compile_procedure_call(target, linkage) {
-    const primitive_branch = make_label("primitive-branch");
-    const compiled_branch = make_label("compiled-branch");
-    const after_call = make_label("after-call");
+    const primitive_branch = make_label("primitive_branch");
+    const compiled_branch = make_label("compiled_branch");
+    const after_call = make_label("after_call");
 
     const compiled_linkage = linkage === "next" ? after_call : linkage;
     
@@ -649,7 +649,7 @@ function compile_procedure_call(target, linkage) {
     </SCHEME>
     <JAVASCRIPT>
 function compile_proc_appl(target, linkage) {
-    if (target === "val" && linkage !== "return") {
+    if (target === "val" &amp;&amp; linkage !== "return") {
         return make_instruction_sequence(
             list("proc"),
             all_regs,
@@ -657,7 +657,7 @@ function compile_proc_appl(target, linkage) {
                 assign("continue", list(label(linkage))),
                 assign("val", list(op("compiled_procedure_entry"), reg("proc"))),
                 go_to(reg("val"))));
-    } else if (target !== "val" && linkage !== "return") {
+    } else if (target !== "val" &amp;&amp; linkage !== "return") {
         const proc_return = make_label("proc_return");
 
         return make_instruction_sequence(
@@ -670,14 +670,14 @@ function compile_proc_appl(target, linkage) {
                 proc_return,
                 assign(target, list(reg("val"))),
                 go_to(label(linkage))));
-    } else if (target === "val" && linkage === "return") {
+    } else if (target === "val" &amp;&amp; linkage === "return") {
         return make_instruction_sequence(
             list("proc", "continue"),
             all_regs,
             list(
                 assign("val", list(op("compiled_procedure_entry"), reg("proc"))),
                 go_to(reg("val"))));
-    } else if (target !== "val" && linkage === "return") {
+    } else if (target !== "val" &amp;&amp; linkage === "return") {
         error(target, "return linkage, target not val - - COMPILE");
     }
 }
diff --git a/xml/chapter5/section5/subsection4.xml b/xml/chapter5/section5/subsection4.xml
index 5eedc5c22..177da6257 100644
--- a/xml/chapter5/section5/subsection4.xml
+++ b/xml/chapter5/section5/subsection4.xml
@@ -242,7 +242,7 @@ function preserving(regs, seq1, seq2) {
     } else {
         const first_reg = head(regs);
 
-        if (need_register(seq2, first_reg) && modifies_register(seq1, first_reg)) {
+        if (need_register(seq2, first_reg) &amp;&amp; modifies_register(seq1, first_reg)) {
             return preserving(
                 tail(regs),
                 make_instruction_sequence(
@@ -301,7 +301,7 @@ function tack_on_instruction_sequence(seq, body_seq) {
 
       <TEXT>
   <SPLITINLINE><SCHEME><SCHEMEINLINE>Compile-if</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>Compile_if</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME><SCHEMEINLINE>compile-procedure-call</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>compile_procedure_call</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> use a special
-  combiner called <SCHEMEINLINE>parallel-instruction-sequences</SCHEMEINLINE> to append the two
+  combiner called <SPLITINLINE><SCHEME><SCHEMEINLINE>parallel-instruction-sequences</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>parallel_instruction_sequences</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to append the two
   alternative branches that follow a test.  The two branches will never be
   executed sequentially; for any particular evaluation of the test, one
   branch or the other will be entered.  Because of this, the registers needed by the second branch are still needed by the combined sequence,
diff --git a/xml/chapter5/section5/subsection5.xml b/xml/chapter5/section5/subsection5.xml
index 938c7cf28..61ed4565c 100644
--- a/xml/chapter5/section5/subsection5.xml
+++ b/xml/chapter5/section5/subsection5.xml
@@ -144,7 +144,7 @@ assign("val", constant(ok));
                      reg("env"))),
   $\langle \textit{compilation of procedure body} \rangle$
 "after_lambda1",
-  perform(op("define-variable"), 
+  perform(op("define_variable"), 
           constant("factorial"), 
           reg("val"), 
           reg("env")),
@@ -356,7 +356,7 @@ function factorial_alt(n) {
     <JAVASCRIPT>
 function factorial(n) {
     function iter(product, counter) {
-        return counter > n
+        return counter &gt; n
             ? product
             : iter(product * counter, counter + 1);
     }
@@ -655,7 +655,7 @@ function factorial(n) {
       (assign val (op +) (reg val) (const 1))
     </SCHEME>
     <JAVASCRIPT>
-assign("val", op("lookup-variable-value"), constant("a"), reg("env")),
+assign("val", op("lookup_variable_value"), constant("a"), reg("env")),
 assign("val", op("+"), reg("val"), constant(1)),
     </JAVASCRIPT>
   </SNIPPET>
diff --git a/xml/chapter5/section5/subsection6.xml b/xml/chapter5/section5/subsection6.xml
index abe55782f..fb0feda03 100644
--- a/xml/chapter5/section5/subsection6.xml
+++ b/xml/chapter5/section5/subsection6.xml
@@ -70,7 +70,8 @@ let y = 4;
   structure that parallels the lexical structure of the program in which
   the expression appears.<FOOTNOTE>This is not true if we allow
     internal definitions, unless we scan them out.
-    See exercise<SPACE/><REF NAME="ex:compile-internal-defs"/>.</FOOTNOTE>
+    See exercise<SPACE/><REF NAME="ex:lexical-address-end"/>. <!-- Note: should be ex:compile-internal-defs but labels are broken. -->
+  </FOOTNOTE>
   Thus, the compiler can know, when it analyzes the
   above expression, that each time the
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
@@ -168,15 +169,16 @@ let y = 4;
     <INDEX>scanning out internal definitions<SUBINDEX>compiler@in compiler</SUBINDEX></INDEX>
     <INDEX>compiler for Scheme<SUBINDEX>scanning out internal definitions</SUBINDEX></INDEX>
     required if we implement the scanning method to eliminate internal
-    definitions (exercise<SPACE/><REF NAME="ex:compile-internal-defs"/>).  We will need
+    definitions (exercise<SPACE/><REF NAME="ex:lexical-address-end"/>). <!-- Note: should be ex:compile-internal-defs but labels are broken. -->
+    We will need
     to eliminate these definitions in order for lexical addressing to
     work.</FOOTNOTE> Also write a
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   <SPLITINLINE><SCHEME><SCHEMEINLINE>lexical-address-set!</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>lexical_address_set</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> that
   implements the operation that changes the value of the variable at a
   specified lexical address.
-  <LABEL NAME="ex:lexical-address-lookup"/>
   <LABEL NAME="ex:lexical-address-start"/>
+  <LABEL NAME="ex:lexical-address-lookup"/>
       </EXERCISE>
 
       <EXERCISE>
@@ -243,7 +245,7 @@ let y = 4;
       <EXERCISE>
   Using <SPLITINLINE><SCHEME><SCHEMEINLINE>find-variable</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>find_variable</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> from exercise<SPACE/><REF NAME="ex:find-variable"/>,
   rewrite <SPLITINLINE><SCHEME><SCHEMEINLINE>compile-variable</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>compile_variable</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> and <SPLITINLINE><SCHEME><SCHEMEINLINE>compile-assignment</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>compile_assignment</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> to output
-  lexical-address instructions.  In cases where <SCHEMEINLINE>find-variable</SCHEMEINLINE>
+  lexical-address instructions.  In cases where <SPLITINLINE><SCHEME><SCHEMEINLINE>find-variable</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>find_variable</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE>
   returns <SPLITINLINE><SCHEME><SCHEMEINLINE>not-found</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>not_found</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> (that is, where the variable is not in the
   compile-time environment), you should have the code generators use the
   evaluator operations, as before, to search for the binding.
@@ -253,7 +255,8 @@ let y = 4;
   environment.<FOOTNOTE>Lexical addresses cannot be used to access variables in the global
     environment, because these names can be defined and redefined
     interactively at any time.  With internal definitions scanned out, as
-    in exercise<SPACE/><REF NAME="ex:compile-internal-defs"/>, the only definitions the
+    in exercise<SPACE/><REF NAME="ex:lexical-address-end"/>, <!-- Note: should be ex:compile-internal-defs but labels are broken. -->
+    the only definitions the
     compiler sees are those at top level, which act on the global
     environment.  Compilation of a definition does not cause the defined
     name to be entered in the compile-time environment.</FOOTNOTE>
@@ -280,8 +283,8 @@ let y = 4;
   the compiler to perform the same transformation before it compiles a
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   body.
-  <LABEL NAME="ex:compile-internal-defs"/>
   <LABEL NAME="ex:lexical-address-end"/>
+  <LABEL NAME="ex:compile-internal-defs"/>
       </EXERCISE>
 
       <EXERCISE>
diff --git a/xml/chapter5/section5/subsection7.xml b/xml/chapter5/section5/subsection7.xml
index 14aaa12ee..6c24bc787 100644
--- a/xml/chapter5/section5/subsection7.xml
+++ b/xml/chapter5/section5/subsection7.xml
@@ -16,7 +16,7 @@
   a
   <SPLITINLINE><SCHEME>procedure</SCHEME><JAVASCRIPT>function</JAVASCRIPT></SPLITINLINE>
   <!--  \indcode{compile-and-go} -->
-  <SCHEMEINLINE>compile-and-go</SCHEMEINLINE> that compiles a Scheme expression, loads the
+  <SPLITINLINE><SCHEME><SCHEMEINLINE>compile-and-go</SCHEMEINLINE></SCHEME><JAVASCRIPT><JAVASCRIPTINLINE>compile_and_go</JAVASCRIPTINLINE></JAVASCRIPT></SPLITINLINE> that compiles a Scheme expression, loads the
   resulting object code into the evaluator machine,
   and causes the machine to run the code in the
   evaluator global environment, print the result, and
@@ -167,7 +167,7 @@ function start_eceval() {
     <JAVASCRIPT>
 branch(label("external_entry")), // branches if flag is set
 "read_eval_print_loop",
-perform(op("initialize-stack")),
+perform(op("initialize_stack")),
 $\langle\ldots\rangle$
     </JAVASCRIPT>
   </SNIPPET>
@@ -277,7 +277,7 @@ function user_print(object) {
 <!--  \indcode*{compile-and-go} -->
 function compile_and_go(expression) {
     const instructions = assemble(statements(compile(expression, "val", "return")), "eceval");
-    the-global-environment = setup-environment();
+    the_global_environment = setup_environment();
     set_register_contents("eceval", "val", instructions);
     set_register_contents("eceval", "flag", true);
     return start("eceval");