From: jim Date: Tue, 24 Mar 2015 14:28:50 +0000 (-0400) Subject: more results that aren't terms X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=commitdiff_plain;h=da4f03bb61847d94efa5c0f91979b7bbfb5b2e26 more results that aren't terms --- 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 -----------------------------------------------