From 042bd457e1260fd3a46b60c44fb1e878abb5bff4 Mon Sep 17 00:00:00 2001
From: Martin Henz <henz@comp.nus.edu.sg>
Date: Tue, 30 Jun 2020 14:10:56 +0800
Subject: [PATCH 1/2] fixes #268

---
 xml/chapter1/section2/subsection1.xml |   1 -
 xml/chapter1/section3/subsection2.xml |   4 +-
 xml/chapter1/section3/subsection3.xml |   2 +-
 xml/chapter3/section2/subsection1.xml |   9 +-
 xml/chapter3/section2/subsection4.xml | 234 ++++++++--------
 xml/chapter4/section1/section1.xml    |  85 +++---
 xml/chapter4/section1/subsection1.xml | 373 ++++++++++++++++----------
 xml/chapter4/section1/subsection2.xml |   4 +-
 xml/chapter4/section1/subsection3.xml |   1 -
 xml/chapter4/section1/subsection4.xml |   4 +-
 xml/chapter4/section1/subsection6.xml |  98 ++++---
 xml/chapter4/section1/subsection7.xml |  20 +-
 xml/chapter4/section2/subsection2.xml |  14 +-
 xml/chapter4/section3/subsection3.xml |   8 +-
 xml/chapter4/section4/subsection4.xml |  10 +-
 15 files changed, 461 insertions(+), 406 deletions(-)

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..c5bbc262b 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>
@@ -306,7 +305,8 @@ function f(x) {
       </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,13 +324,10 @@ 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.
@@ -366,7 +363,7 @@ function f(x) {
                           v = b;
                           $\textit{statements}$
 		      })($e_1$, $e_2$);
-           })("*unassigned*", "*unassigned*");
+           })(unassigned, unassigned);
 }
 	  </JAVASCRIPT>
 	</SNIPPET>
@@ -433,34 +430,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 +468,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>
@@ -534,17 +524,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..e6dcfec26 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>
@@ -570,11 +563,9 @@ 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>
@@ -718,13 +709,14 @@ analyze_block(parse("{ const x = 4; x; }"))
     </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));
 }
@@ -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 7f6fc4c4d..ee48c7bcb 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)

From 69284e6e30bc8720e9ff1ebde349d86f95a4debb Mon Sep 17 00:00:00 2001
From: Martin Henz <henz@comp.nus.edu.sg>
Date: Tue, 30 Jun 2020 14:35:52 +0800
Subject: [PATCH 2/2] exercise didn't make any sense any longer

---
 xml/chapter4/section1/subsection7.xml | 122 +++++++++++++-------------
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/xml/chapter4/section1/subsection7.xml b/xml/chapter4/section1/subsection7.xml
index e6dcfec26..a681a1e4a 100644
--- a/xml/chapter4/section1/subsection7.xml
+++ b/xml/chapter4/section1/subsection7.xml
@@ -562,7 +562,6 @@ 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 bfun = analyze(body);
     return env =>
            make_function(parameters, bfun, env);
@@ -668,51 +667,54 @@ 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>
-      <REQUIRES>list_of_unassigned</REQUIRES>
-      <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);	    
@@ -720,28 +722,38 @@ function analyze_block(stmt) {
     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>
@@ -875,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>