Implementing Lexical Scope: Closures and Environments

So how do we fix this?

Lets go back to the root of the problem: the new evaluator does not behave in the same way as the substituting evaluator. In the old evaluator, it was easy to see how functions can behave as objects that remember values. For example, when we do this:

the result was a function value, which actually was the syntax object for this:

Now if we call this function from someplace else like:

it is clear what the result will be: f is bound to a function that adds 1 to its input, so in the above the later binding for x has no effect at all.

But with the caching evaluator, the value of

is simply:

and there is no place where we save the 1 — that’s the root of our problem. (That’s also what makes people suspect that using lambda in Racket and any other functional language involves some inefficient code-recompiling magic.) In fact, we can verify that by inspecting the returned value, and see that it does contain a free identifier.

Clearly, we need to create an object that contains the body and the argument list, like the function syntax object — but we don’t do any substitution, so in addition to the body an argument name(s) we need to remember that we still need to substitute x by 1 . This means that the pieces of information we need to know are:

and that last bit has the missing 1. The resulting object is called a closure because it closes the function body over the substitutions that are still pending (its environment).

So, the first change is in the value of functions which now need all these pieces, unlike the Fun case for the syntax object.

A second place that needs changing is the when functions are called. When we’re done evaluating the call arguments (the function value and the argument value) but before we apply the function we have two values — there is no more use for the current substitution cache at this point: we have finished dealing with all substitutions that were necessary over the current expression — we now continue with evaluating the body of the function, with the new substitutions for the formal arguments and actual values given. But the body itself is the same one we had before — which is the previous body with its suspended substitutions that we still did not do.

Rewrite the evaluation rules — all are the same except for evaluating a fun form and a call form:

As a side note, these substitution caches are a little more than “just a cache” now — they actually hold an environment of substitutions in which expression should be evaluated. So we will switch to the common environment name now.:

In case you find this easier to follow, the “flat algorithm” for evaluating a call is:

Note how the scoping rules that are implied by this definition match the scoping rules that were implied by the substitution-based rules. (It should be possible to prove that they are the same.)

The changes to the code are almost trivial, except that we need a way to represent <{fun {x} B}, env> pairs.

---

The implication of this change is that we now cannot use the same type for function syntax and function values since function values have more than just syntax. There is a simple solution to this — we never do any substitutions now, so we don’t need to translate values into expressions — we can come up with a new type for values, separate from the type of abstract syntax trees.

When we do this, we will also fix our hack of using FLANG as the type of values: this was merely a convenience since the AST type had cases for all kinds of values that we needed. (In fact, you should have noticed that Racket does this too: numbers, strings, booleans, etc are all used by both programs and syntax representation (s-expressions) — but note that function values are not used in syntax.) We will now implement a separate VAL type for runtime values.

First, we need now a type for such environments — we can use Listof for this:

but we can just as well define a new type for environment values:

Reimplementing lookup is now simple:

… we don’t need extend because we get Extend from the type definition, and we also get (EmptyEnv) instead of empty-subst.

We now use this with the new type for values — two variants of these:

And now the new implementation of eval which uses the new type and implements lexical scope:

We also need to update arith-op to use VAL objects. The full code follows — it now passes all tests, including the example that we used to find the problem.

Fixing an Overlooked Bug

Incidentally, this version fixes a bug we had previously in the substitution version of FLANG:

This bug was due to our naive subst, which doesn’t avoid capturing renames. But note that since that version of the evaluator makes its way from the outside in, there is no difference in semantics for valid programs — ones that don’t have free identifiers.

(Reminder: This was not a dynamically scoped language, just a bug that happened when x wasn’t substituted away before f was replaced with something that refers to x.)

Lexical Scope using Racket Closures

PLAI §11 (without the last part about recursion)

An alternative representation for an environment.

We’ve already seen how first-class functions can be used to implement “objects” that contain some information. We can use the same idea to represent an environment. The basic intuition is — an environment is a mapping (a function) between an identifier and some value. For example, we can represent the environment that maps 'a to 1 and 'b to 2 (using just numbers for simplicity) using this function:

An empty mapping that is implemented in this way has the same type:

We can use this idea to implement our environments: we only need to define three things — EmptyEnv, Extend, and lookup. If we manage to keep the contract to these functions intact, we will be able to simply plug it into the same evaluator code with no other changes. It will also be more convenient to define ENV as the appropriate function type for use in the VAL type definition instead of using the actual type:

Now we get to EmptyEnv — this is expected to be a function that expects no arguments and creates an empty environment, one that behaves like the empty-mapping function defined above. We could define it like this (changing the empty-mapping type to return a VAL):

but we can skip the need for an extra definition and simply return an empty mapping function:

(The un-Rackety name is to avoid replacing previous code that used the EmptyEnv name for the constructor that was created by the type definition.)

The next thing we tackle is lookup. The previous definition that was used is:

How should it be modified now? Easy — an environment is a mapping: a Racket function that will do the searching job itself. We don’t need to modify the contract since we’re still using ENV, except a different implementation for it. The new definition is:

Note that lookup does almost nothing — it simply delegates the real work to the env argument. This is a good hint for the error message that empty mappings should throw —

Finally, Extend — this was previously created by the variant case of the ENV type definition:

keeping the same type that is implied by this variant means that the new Extend should look like this:

The question is — how do we extend a given environment? Well, first, we know that the result should be mapping — a symbol -> VAL function that expects an identifier to look for:

Next, we know that in the generated mapping, if we look for id then the result should be val:

If the name that we’re looking for is not the same as id, then we need to search through the previous environment:

But we know what lookup does — it simply delegates back to the mapping function (which is our rest argument), so we can take a direct route instead:

To see how all this works, try out extending an empty environment a few times and examine the result. For example, the environment that we began with:

behaves in the same way (if the type of values is numbers) as

The new code is now the same, except for the environment code:

More Closures (on both levels)

Racket closures (= functions) can be used in other places too, and as we have seen, they can do more than encapsulate various values — they can also hold the behavior that is expected of these values.

To demonstrate this we will deal with closures in our language. We currently use a variant that holds the three pieces of relevant information:

We can replace this by a functional object, which will hold the three values. First, change the VAL type to hold functions for FunV values:

And note that the function should somehow encapsulate the same information that was there previously, the question is how this information is going to be done, and this will determine the actual type. This information plays a role in two places in our evaluator — generating a closure in the Fun case, and using it in the Call case:

we can simply fold the marked functionality bit of Call into a Racket function that will be stored in a FunV object — this piece of functionality takes an argument value, extends the closure’s environment with its value and the function’s name, and continues to evaluate the function body. Folding all of this into a function gives us:

where the values of bound-body, bound-id, and val are known at the time that the FunV is constructed. Doing this gives us the following code for the two cases:

And now the type of the function is clear:

And again, the rest of the code is unmodified:

Types of Evaluators

What we did just now is implement lexical environments and closures in the language we implement using lexical environments and closures in our own language (Racket)!

This is another example of embedding a feature of the host language in the implemented language, an issue that we have already discussed.

There are many examples of this, even when the two languages involved are different. For example, if we have this bit in the C implementation of Racket:

then the special semantics of evaluating a Racket and form is being inherited from C’s special treatment of &&. You can see this by the fact that if there is a bug in the C compiler, then it will propagate to the resulting Racket implementation too. A different solution is to not use && at all:

and we can say that this is even better since it evaluates the second expression in tail position. But in this case we don’t really get that benefit, since C itself is not doing tail-call optimization as a standard feature (though some compilers do so under some circumstances).

We have seen a few different implementations of evaluators that are quite different in flavor. They suggest the following taxonomy.

• A syntactic evaluator is one that uses its own language to represent expressions and semantic runtime values of the evaluated language, implementing all the corresponding behavior explicitly.

• A meta evaluator is an evaluator that uses language features of its own language to directly implement behavior of the evaluated language.

While our substitution-based FLANG evaluator was close to being a syntactic evaluator, we haven’t written any purely syntactic evaluators so far: we still relied on things like Racket arithmetics etc. The most recent evaluator that we have studied, is even more of a meta evaluator than the preceding ones: it doesn’t even implement closures and lexical scope, and instead, it uses the fact that Racket itself has them.

With a good match between the evaluated language and the implementation language, writing a meta evaluator can be very easy. With a bad match, though, it can be very hard. With a syntactic evaluator, implementing each semantic feature will be somewhat hard, but in return you don’t have to worry as much about how well the implementation and the evaluated languages match up. In particular, if there is a particularly strong mismatch between the implementation and the evaluated language, it may take less effort to write a syntactic evaluator than a meta evaluator.

As an exercise, we can build upon our latest evaluator to remove the encapsulation of the evaluator’s response in the VAL type. The resulting evaluator is shown below. This is a true meta evaluator: it uses Racket closures to implement FLANG closures, Racket function application for FLANG function application, Racket numbers for FLANG numbers, and Racket arithmetic for FLANG arithmetic. In fact, ignoring some small syntactic differences between Racket and FLANG, this latest evaluator can be classified as something more specific than a meta evaluator:

• A meta-circular evaluator is a meta evaluator in which the implementation and the evaluated languages are the same.

  This is essentially the concept of a “universal” evaluator, as in a “universal turing machine”.

(Put differently, the trivial nature of the evaluator clues us in to the deep connection between the two languages, whatever their syntactic differences may be.)

Feature Embedding

We saw that the difference between lazy evaluation and eager evaluation is in the evaluation rules for with forms, function applications, etc:

is eager, and

is lazy. But is the first rule really eager? The fact is that the only thing that makes it eager is the fact that our understanding of the mathematical notation is eager — if we were to take math as lazy, then the description of the rule becomes a description of lazy evaluation.

Another way to look at this is — take the piece of code that implements this evaluation:

and the same question applies: is this really implementing eager evaluation? We know that this is indeed eager — we can simply try it and check that it is, but it is only eager because we are using an eager language for the implementation! If our own language was lazy, then the evaluator’s implementation would run lazily, which means that the above applications of the eval and the subst functions would also be lazy, making our evaluator lazy as well.

This is a general phenomena where some of the semantic features of the language we use (math in the formal description, Racket in our code) gets embedded into the language we implement.

Here’s another example — consider the code that implements arithmetics:

what if it was written like this:

Would it still implement unlimited integers and exact fractions? That depends on the language that was used to implement it: the above syntax suggests C, C++, Java, or some other relative, which usually come with limited integers and no exact fractions. But this really depends on the language — even our own code has unlimited integers and exact rationals only because Racket has them. If we were using a language that didn’t have such features (there are such Scheme implementations), then our implemented language would absorb these (lack of) features too, and its own numbers would be limited in just the same way. (And this includes the syntax for numbers, which we embedded intentionally, like the syntax for identifiers).

The bottom line is that we should be aware of such issues, and be very careful when we talk about semantics. Even the language that we use to communicate (semi-formal logic) can mean different things.

---

Aside: read “Reflections on Trusting Trust” by Ken Thompson (You can skip to the “Stage II” part to get to the interesting stuff.)

(And when you’re done, look for “XcodeGhost” to see a relevant example, and don’t miss the leaked document on the wikipedia page…)

---

Here is yet another variation of our evaluator that is even closer to a meta-circular evaluator. It uses Racket values directly to implement values, so arithmetic operations become straightforward. Note especially how the case for function application is similar to arithmetics: a FLANG function application translates to a Racket function application. In both cases (applications and arithmetics) we don’t even check the objects since they are simple Racket objects — if our language happens to have some meaning for arithmetics with functions, or for applying numbers, then we will inherit the same semantics in our language. This means that we now specify less behavior and fall back more often on what Racket does.

We use Racket values with this type definition:

And the evaluation function can now be:

Note how the arithmetics implementation is simple — it’s a direct translation of the FLANG syntax to Racket operations, and since we don’t check the inputs to the Racket operations, we let Racket throw type errors for us. Note also how function application is just like the arithmetic operations: a FLANG application is directly translated to a Racket application.

However, this does not work quite as simply in Typed Racket. The whole point of typechecking is that we never run into type errors — so we cannot throw back on Racket errors since code that might produce them is forbidden! A way around this is to perform explicit checks that guarantee that Racket cannot run into type errors. We do this with the following two helpers that are defined inside eval:

Note that Typed Racket is “smart enough” to figure out that in evalF the result of the recursive evaluation has to be either Number or (VAL -> VAL); and since the if throws out on numbers, we’re left with (VAL -> VAL) functions, not just any function.