Generally, we know how lazy evaluation works when we use the substitution model. We even know that if we have:
then the result should be an error because we cannot substitute the y
expression in because it will capture the y — changing the binding
structure. As an indication, the original expression contains a free
reference to y, which is exactly why we shouldn’t substitute it. But
what about:
Evaluating this eagerly returns 18, we therefore expect any other evaluation (eager or lazy, using substitutions or environments) to return 18 too, because any of these options should not change the meaning of numbers, of addition, or of the scoping rules. (And we know that no matter what evaluation strategy we choose, if we get to a value (no infinite loop or exception) then it’ll always be the same value.) For example, try using lazy evaluation with substitutions:
And what about lazy evaluation using environments:
We have a problem! This problem should be familiar now, it is very similar to the problem that led us down the mistaken path of dynamic scoping when we tried to have first-class functions. In both cases, substitution always worked, and it looks like in both cases the problem is that we don’t remember the environment of an expression: in the case of functions, it is the environment at the time of creating the closure that we want to capture and use when we go back later to evaluate the body of the function. Here we have a similar situation, except that we don’t need a function to defer computation: most expressions get evaluated at some time in the future, so every time we defer such a computation we need to remember the lexical environment of the expression.
This is the major point that will make things work again: every expression creates something like a closure — an object that closes over an expression and an environment at the (lexical) place where that expression was used, and when we actually want to evaluate it later, we need to do it in the right lexical context. So it is like a closure except it doesn’t need to be applied, and there are no arguments. In fact it is also a form of a closure — instead of closing over a function body and an environment, it closes over any expression and an environment. (As we shall see, lazy evaluation is tightly related to using nullary functions: thunks.)
So we implement this by creating such closure values for all expressions that are not evaluated right now. We begin with the Toy language, and rename it to “Sloth”. We then add one more case to the data type of values which implements the new kind of expression closures, which contains the expression and its environment:
(Intuition#1: ExprV is a delayed evaluation and therefore it has the
two values that are ultimately passed to eval. Intuition#2: laziness
can be implemented with thunks, so we hold the same information as a
FunV does, only there’s no need for the argument names.)
Where should we use the new ExprV? — At any place where we want to
be lazy and defer evaluating an expression for later. The two places in
the interpreter where we want to delay evaluation are the named
expressions in a bind form and the argument expressions in a function
application. Both of these cases use the helper eval* function to do
their evaluations, for example:
To delay these evaluations, we need to change eval* so it returns an
expression closure instead of actually doing the evaluation — change:
to:
Note how simple this change is — instead of an eval function call,
we create a value that contains the parts that would have been used in
the eval function call. This value serves as a promise to do this
evaluation (the eval call) later, if needed. (This is exactly why a
Lazy Racket would make this a lazy evaluator: in it, all function
calls are promises.)
Side note: this can be used in any case when you’re using an eager language, and you want to delay some function call — all you need to do is replace (using a C-ish syntax)
with
now all calls to foo return a delayed_foo instance instead of an
integer. Whenever we want to force the delayed promise, we can use this
function:
You might even want to make sure that each such promise is evaluated exactly once — this is simple to achieve by adding a cache field to the struct:
As we will see shortly, this corresponds to switching from a call-by-name lazy language to a call-by-need one.
Back to our Sloth interpreter — given the eval* change, we expect
that eval-uating:
will return:
and the same goes for eval-uating
Similarly, evaluating
should return
But what about evaluating an expression like this one:
?
Using what we have so far, we will get to evaluate the body, which is a
(Call …) expression, but when we evaluate the arguments for this
function call, we will get ExprV values — so we will not be able to
perform the addition. Instead, we will get an error from the function
that racket-func->prim-val creates, due to the value being an ExprV
instead of a RktV.
What we really want is to actually add two values, not promises. So
maybe distinguish the two applications — treat PrimV differently
from FunV closures?
This still doesn’t work — the problem is that the function now gets a
bunch of values, where some of these can still be ExprVs because the
evaluation itself can return such values… Another way to see this
problem is to consider the code for evaluating an If conditional
expression:
…we need to take care of a possible ExprV here. What should we do?
The obvious solution is to use eval if we get an ExprV value:
Note how this translates back the data structure that represents a
delayed eval promise back into a real eval call…
Going back to our code for Call, there is a problem with it — the
will indeed evaluate the expression instead of lazily deferring this to the future, but this evaluation might itself return such lazy values. So we need to inspect the resulting value again, forcing the promise if needed:
But we still have a problem — programs can get an arbitrarily long
nested chains of ExprVs that get forced to other ExprVs.
What we really need is to write a loop that keeps forcing promises over
and over until it gets a proper non-ExprV value.
Note that it’s close to real-eval*, but there’s no need to mix it with
eval. The recursive call is important: we can never be sure that
eval didn’t return an ExprV promise, so we have to keep looping
until we get a “real” value.
Now we can change the evaluation of function calls to something more manageable:
The code is fairly similar to what we had previously — the only
difference is that we wrap a strict call where a proper value is
needed — the function value itself, and arguments to primitive
functions.
The If case is similar (note that it doesn’t matter if strict is
used with the result of eval or eval* (which returns an ExprV)):
Note that, like before, we always return #t for non-RktV values —
this is because we know that the value there is never an ExprV. All we
need now to get a working evaluator, is one more strictness point: the
outermost point that starts our evaluation — run — needs to use
strict to get a proper result value.
With this, all of the tests that we took from the Toy evaluator run successfully. To make sure that the interpreter is lazy, we can add a test that will fail if the language is strict:
[In fact, we can continue and replace all eval calls with ExprV,
leaving only the one call in strict. This doesn’t make any difference,
because the resulting promises will eventually be forced by strict
anyway.]
As we’ve seen, using strict in places where we need an actual value
rather than a delayed promise is enough to get a working lazy evaluator.
Our current implementation assumes that all primitive functions need
strict values, therefore the argument values are all passed through the
strict function — but this is not always the case. Specifically, if
we have constructor functions, then we don’t need (and usually don’t
want) to force the promises. This is basically what allows us to use
infinite lists in Lazy Racket: the fact that list and cons do not
require forcing their arguments.
To allow some primitive functions to consume strict values and some to
leave them as is, we’re going to change racket-func->prim-val and add
a flag that indicates whether the primitive function is strict or not.
Obviously, we also need to move the strict call around arguments to a
primitive function application into the racket-func->prim-val
generated function — which simplifies the Call case in eval (we go
from (proc (map strict arg-vals)) back to (proc arg-vals)). The new code
for racket-func->prim-val and its helper is:
We now need to annotate the primitives in the global environment, as well as add a few constructors:
Note that this last change raises a subtle type issue: we’re actually
abusing the Racket list and cons constructors to hold Sloth values.
One way in which this becomes a problem is the current assumption that a
primitive function always returns a Racket value (it is always wrapped
in a RktV) — but this is no longer the case for first and rest:
when we use
in Sloth, the resulting value will be
This leads to two problems: first, if we use Racket’s first and
rest, they will complain (throw a runtime error) since the input value
is not a proper list (it’s a pair that has a non-list value in its
tail). To resolve that, we use the more primitive car and cdr
functions to implement Sloth’s first and rest.
The second problem happens when we try and grab the first value of this
we will eventually get back the ExprV and wrap it in a RktV:
and finally run will strip off the RktV and return the ExprV. A
solution to this is to make our first and rest functions return a
value without wrapping it in a RktV — we can identify this
situation by the fact that the returned value is already a VAL instead
of some other Racket value. We can identify such values with the VAL?
predicate that gets defined by our define-type, implemented by a new
wrap-in-val helper:
Note that we don’t need to worry about the result being an ExprV —
that will eventually be taken care of by strict.