Getting more from Sloth

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.

The Sloth Implementation

The complete Sloth code follows. It can be used to do the same fun things we did with Lazy Racket.

Shouldn’t there be more ExprV promises?

You might notice that there are some apparently missing promises. For example, consider our evaluation of Bind forms:

The named expressions are turned into expression promises via eval*, but shouldn’t we change the first eval (the one that evaluates the body) into a promise too? This is a confusing point, and the bottom line is that there is no need to create a promise there. The main idea is that the eval function is actually called from contexts that actually need to be evaluated. One example is when we force a promise via strict, and another one is when run calls eval. Note that in both of these cases, we actuallly need a (forced) value, so creating a promise in there doesn’t make any difference.

To see this differently, consider how bind might be used within the language. The first case is when bind is the topmost expression, or part of a bind “spine”:

In these cases we evaluate the bind expression when we need to return a result for the whole run, so adding an ExprV is not going to make a difference. The second case is when bind is used in an expression line a function argument:

Here there is also no point in adding an ExprV to the Bind case, since the evaluation of the whole argument (the Bind value) will be wrapped in an ExprV, so it is already delayed. (And when it get forced, we will need to do the bind evaluation anyway, so again, it adds no value.)

A generalization of this is that when we actually call eval (either directly or via strict), there is never any point in making the result that it returns a promise.

(And if you’ll follow this carefully and look at all of the eval calls, you will see that this means that neither of the eval*s in the If case are needed!)

Implementing Call by Need

As we have seen, there are a number of advantages for lazy evaluation, but its main disadvantage is the fact that it is extremely inefficient, to the point of rendering lots of programs impractical, for example, in:

we end up adding 4 and 5 twice. In other words, we don’t suffer from textual redundancy (each expression is written once), but we don’t avoid dynamic redundancy. We can get it back by simply caching evaluation results, using a box that will be used to remember the results. The box will initially hold #f, and it will change to hold the VAL that results from evaluation:

We need a utility function to create an evaluation promise, because when an ExprV is created, its initial cache box needs to be initialized.

(And note that Typed Racket needs to figure out that the #f in this definition has a type of (U #f VAL) and not just #f.)

This eval-promise is used instead of ExprV in eval. Finally, whenever we force such an ExprV promise, we need to check if it was already evaluated, otherwise force it and cache the result. This is simple to do since there is a single field that is used both as a flag and a cached value:

But note that this makes using side-effects in our interpreter even more confusing. (It was true with call-by-name too.)

The resulting code follows.