We will see how to add a similar construct to our language — for
simplicity, we will add a
rec form that handles a single binding:
Using this, things can get a little tricky. What should we get if we do:
? Currently, it seems like there is no point in using any expression
except for a function expression in a
rec expression, so we will
handle only these cases.
(BTW, under what circumstances would non-function values be useful in a letrec?)
One way to achieve this is to use the same trick that we have recently seen: instead of re-implementing language features, we can use existing features in our own language, which hopefully has the right functionality in a form that can be re-used to in our evaluator.
Previously, we have seen a way to implement environments using Racket closures:
We can use this implementation, and create circular environments using
letrec. The code for handling a
with expressions is:
It looks like we should be able to handle
rec in a similar way (the
AST constructor name is
WRec (“with-rec”) so it doesn’t collide with
Rec constructor for recursive types):
but this won’t work because the named expression is evaluated
prematurely, in the previous environment. Instead, we will move
everything that needs to be done, including evaluation, to a separate
extend-rec function needs to provide the new, “magically
circular” environment. Following what we know about the arguments to
extend-rec, and the fact that it returns a new environment (= a lookup
function), we can sketch a rough definition:
What should the missing expression be? It can simply evaluate the object given itself:
But how do we get this environment, before it is defined? Well, the
environment is itself a Racket function, so we can use Racket’s
letrec to make the function refer to itself recursively:
It’s a little more convenient to use an internal definition, and add a type for clarity:
This works, but there are several problems:
First, we no longer do a simple lookup in the new environment. Instead, we evaluate the expression on every such lookup. This seems like a technical point, because we do not have side-effects in our language (also because we said that we want to handle only function expressions). Still, it wastes space since each evaluation will allocate a new closure.
Second, a related problem — what happens if we try to run this:
? Well, we do that stuff to extend the current environment, then evaluate the body in the new environment, this body is a single variable reference:
so we look up the value:
which goes into the function which implements this environment, there
we see that
name is the same as
name1, so we return:
expr here is the original named-expression which is itself
(Id 'x), and we’re in an infinite loop.
We can try to get over these problems using another binding. Racket
allows several bindings in a single
letrec expression or multiple
internal function definitions, so we change
extend-rec to use the
This runs into an interesting type error, which complains about possibly
Undefined value. It does work if we switch to the
untyped language for now (using
#lang pl untyped) — and it seems to
run fine too. But it raises more questions, beginning with: what is the
or equivalently, an internal block of
? Well, DrRacket seems to do the “right thing” in this case, but what about:
? As a hint, see what happens when we now try to evaluate the problematic
expression, and compare that with the result that you’d get from Racket. This also clarifies the type error that we received.
It should be clear now why we want to restrict usage to just binding
recursive functions. There are no problems with such definitions
because when we evaluate a
fun expression, there is no evaluation of
the body, which is the only place where there are potential references
to the same function that is defined — a function’s body is delayed,
and executed only when the function is applied later.
But the biggest question that is still open: we just implemented a circular environment using Racket’s own circular environment implementation, and that does not explain how they are actually implemented. The cycle of pointers that we’ve implemented depends on the cycle of pointers that Racket uses, and that is a black box we want to open up.
For reference, the complete code is below.
recUsing Cyclic Structures
Looking at the arrows in the environment diagrams, what we’re really
looking for is a closure that has an environment pointer which is the
same environment in which it was defined. This will make it possible
fact to be bound to a closure that can refer to itself since its
environment is the same one in which it is defined. However, so far we
have no tools that makes it possible to do this.
What we need is to create a “cycle of pointers”, and so far we do not have a way of achieving that: when we create a closure, we begin with an environment which is saved in the slot’s environment slot, but we want that closure to be the value of a binding in that same environment.
To actually implement a circular structure, we will now use
side-effects, using a new kind of Racket value which supports
mutation: a box. A box value is built with the
the value is retrieved with the `unbox’ function,
and finally, the value can be changed with the
An important thing to note is that
set-box! is much like
etc, it returns a value that is not printed in the Racket REPL, because
there is no point in using the result of a
set-box!, it is called for
the side-effect it generates. (Languages like C blur this distinction
between returning a value and a side-effect with its assignment
As a side note, we now have side effects of two kinds: mutation of state, and I/O (at least the O part). (Actually, there is also infinite looping that can be viewed as another form of a side effect.) This means that we’re now in a completely different world, and lots of new things can make sense now. A few things that you should know about:
We never used more than one expression in a function body because
there was no point in it, but now there is. To evaluate a sequence of
Racket expressions, you wrap them in a
In most places you don’t actually need to use
begin — these are
places that are said to have an implicit
begin: the body of a
function (or any lambda expression), the body of a
let-relatives), the consequence positions in
cases clauses and more. One of the common places where a
used is in an
if expression (and some people prefer using
instead when there is more than a single expression).
cond without an
else in the end can make sense, if all you’re
using it it for is side-effects.
if could get a single expression which is executed when the
condition is true (and an unspecified value is used otherwise), but
our language (as well as the default Racket language) always forbids
this — there are convenient special forms for a one-sided
unless, and they can have any number of expressions (they
have an implicit
begin). They have an advantage of saying “this
code does some side-effects here” more explicit.
There is a function called
for-each which is just like
that it doesn’t collect the list of results, it is used only for
performing side effects.
When any one of these things is used (in Racket or other languages), you
can tell that side-effects are involved, because there is no point in
any of them otherwise. In addition, any name that ends with a
(“bang”) is used to mark a function that changes state (usually a
function that only changes state).
So how do we create a cycle? Simple, boxes can have any value, and they can be put in other values like lists, so we can do this:
and we get a circular value. (Note how it is printed.) And with types: