From da4f03bb61847d94efa5c0f91979b7bbfb5b2e26 Mon Sep 17 00:00:00 2001 From: jim Date: Tue, 24 Mar 2015 10:28:50 -0400 Subject: [PATCH] more results that aren't terms --- topics/week7_untyped_evaluator.mdwn | 2 ++ 1 file changed, 2 insertions(+) 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 ----------------------------------------------- -- 2.11.0