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 complete Sloth code follows. It can be used to do the same fun things we did with Lazy Racket.

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.