X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=topics%2Fweek7_untyped_evaluator.mdwn;h=7875988b9f41d69d24430b06e339fe1b47902a60;hp=d45b22f9acd872b8f56fb3a252f3ab1114c5f85c;hb=da4f03bb61847d94efa5c0f91979b7bbfb5b2e26;hpb=066a60608e94762510124bb9c8c64ace0afa9b77;ds=sidebyside

diff --git a/topics/week7_untyped_evaluator.mdwn b/topics/week7_untyped_evaluator.mdwn
index d45b22f9..7875988b 100644
--- a/topics/week7_untyped_evaluator.mdwn
+++ b/topics/week7_untyped_evaluator.mdwn
@@ -304,6 +304,8 @@ Here's a better strategy. Instead of keeping all of the information about which
 
 Now `Closure`s are not a new kind of lambda _term_: the syntax for our language doesn't have any constituents that get parsed into `Closure`s. `Closure`s are only created _during the course of evaluating_ terms: specifically, when a variable gets bound to an abstract, which may itself contain variables that are locally free (not bound by the abstract itself). This is why we have separate datatypes for _terms_ and for the _results_ that terms can evaluate to. `Closure`s are results, but they aren't terms. `App`s are terms, but not results. Our boolean and number literals, as well as our primitive functions, constructors, and destructors, are both.
 
+In later weeks, we will see more examples of results that aren't terms, but can only be generated during the course of a computation. (I'm thinking of mutable reference cells. Arguably, partially applied constructors are yet another example, that we're already familiar with.)
+
 
 Getting, reading, and compiling the source code
 -----------------------------------------------