Implementing rec Using Cyclic Structures

PLAI §10

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 for 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.

Boxes and Mutation

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 box constructor:

the value is retrieved with the `unbox’ function,

and finally, the value can be changed with the set-box! function.

An important thing to note is that set-box! is much like display 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 statement.)

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 begin expression.

• 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 (and let-relatives), the consequence positions in cond, match, and cases clauses and more. One of the common places where a begin is used is in an if expression (and some people prefer using cond 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 ifs: when & 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 map, except that it doesn’t collect the list of results, it is used only for performing side effects.

• Aliasing and the concept of “object equality”: equal? vs eq?. For example:

  (: foo : (Boxof ...) (Boxof ...) -> ...)
  (define (foo a b)
    (set-box! a 1)) ;*** this might change b, can check `eq?`

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:

Types for Boxes

Obviously, Any is not too great — it is the most generic type, so it provides the least information. For example, notice that

returns the right list, which is equal to foo itself — but if we try to grab some part of the resulting list:

we get a type error, because the result of the unbox is Any, so Typed Racket knows nothing about it, and won’t allow you to treat it as a list. It is not too surprising that the type constructor that can help in this case is Rec which we have already seen — it allows a type that can refer to itself:

Note that either foo or the value in the box are both printed with a Rec type — the value in the box can’t just have a (U #f this) type, since this doesn’t mean anything in there, so the whole type needs to still be present.

There is another issue to be aware of with Boxof types. For most type constructors (like Listof), if T1 is a subtype of T2, then we also know that(Listof T1) is a subtype of (Listof T2). This makes the following code typecheck:

Since the (Listof Integer) is a subtype of the (Listof Number) input for foo, the application typechecks. But this is not the same for the output type, for example — if we change the bar type to:

we get a type error since Number is not a subtype of Integer. So subtypes are required to “go higher” on the input side and “lower” on the other. So, in a sense, the fact that boxes are mutable means that their contents can be considered to be on the other side of the arrow, which is why for such T1 subtype of T2, it is (Boxof T2) that is a subtype of (Boxof T1), instead of the usual. For example, this doesn’t work:

And you can see why this is the case — the marked line is fine given a Number contents, so if the type checker allows passing in a box holding an integer, then that expression would mutate the contents and make it an invalid value.

However, boxes are not only mutable, they hold a value that can be read too, which means that they’re on both sides of the arrow, and this means that (Boxof T1) is a subtype of (Boxof T2) if T2 is a subtype of T1 and T1 is a subtype of T2 — in other words, this happens only when T1 and T2 are the same type. (See below for an extended demonstration of all of this.)

Note also that this demonstration requires that extra b definition, if it’s skipped:

then this will typecheck again — Typed Racket will just consider the context that requires a box holding a Number, and it is still fine to initialize such a box with an Integer value.

As a side comment, this didn’t always work. Earlier in its existence, Typed Racket would always choose a specific type for values, which would lead to confusing errors with boxes. For example, the above would need to be written as

(define (bar x)
  (foo (box (ann x : Number))))

to prevent Typed Racket from inferring a specific type. This is no longer the case, but there can still be some surprises. A similar annotation was needed in the case of a list holding a self-referential box, to avoid the initial #f from getting a specific-but-wrong type.

Another way to see the problem these days is to enter the following expressions and see what types Typed Racket guesses for them:

> (define a 0)
> (define b (box 0))
> a
- : Integer [more precisely: Zero]        ;***
0
> b
- : (Boxof Integer)                        ;***
'#&0

Note that for a, the assigned type is very specific, because Typed Racket assumes that it will not change. But with a boxed value, using a type of (Boxof Zero) would lead to a useless box, since it’ll only allow using set-box! with 0, and therefore can never change. This shows that this is exactly that: a guess given the lack or explicit user-specified type, so there’s no canonical guess that can be inferred here.

Boxof’s Lack of Subtyping

The lack of any subtype relations between (Boxof T) and (Boxof S) regardless of S and T can roughly be explained as follows.

First, a box is a container that you can pull a value out of — which makes it similar to lists. In the case of lists, we have:

This is true for all such containers that you can pull a value out of: if you expect to pull a T but you’re given a container of a subtype S, then things are still fine (you’ll get an S which is also a T). Such “containers” include functions that produce a value — for example:

However, functions also have the other side, where things are different — instead of a side of some produced value, it’s the side of the consumed value. We get the opposite rule there:

To see why this is right, use Number and Integer for S and T:

so — if you expect a function that takes an integer, a valid subtype value that I can give you is a function that takes a number. In other words, every function that takes a number is also a function that takes an integer, but not the other way.

To summarize all of this, when you make the output type of a function “smaller” (more constrained), the resulting type is smaller (a subset), but on the input side things are flipped — a bigger input type means a more constrained function.

The technical names for these properties are: a “covariant” type is one that preserves the subtype relationship, and a “contravairant” type is one that reverses it. (Which is similar to how these terms are used in math.)

(Side note: this is related to the fact that in logic, P => Q is roughly equivalent to not(P) or Q — the left side, P, is inside negation. It also explains why in ((S -> T) -> Q) the S obeys the first rule, as if it was on the right side — because it’s negated twice.)

Now, a (Boxof T) is a producer of T when you pull a value out of the box, but it’s also a consumer of T when you put such a value in it. This means that — using the above analogy — the T is on both sides of the arrow. This means that

which is actually:

A different way to look at this conclusion is to consider the function type of (A -> A): when is it a subtype of some other (B -> B)? Only when A is a subtype of B and B is a subtype of A, which means that this happens only when A and B are the same type.

The term for this is “nonvariant” (or “invariant”): (A -> A) is unrelated to (B -> B) regardless of how A and B are related. The only exception is, of course, when they are the same type. The Wikipedia entry about these puts the terms together nicely in the face of mutation:

Read-only data types (sources) can be covariant; write-only data types (sinks) can be contravariant. Mutable data types which act as both sources and sinks should be invariant.

The following piece of code makes the analogy to function types more formally. Boxes behave as if their contents is on both sides of a function arrow — on the right because they’re readable, and on the left because they’re writable, which the conclusion that a (Boxof A) type is a subtype of itself and no other (Boxof B).

Implementing a Circular Environment

We now use this to implement rec in the following way:

1. Change environments so that instead of values they hold boxes of values: (Boxof VAL) instead of VAL, and whenever lookup is used, the resulting boxed value is unboxed,

2. In the WRec case, create the new environment with some temporary binding for the identifier — any value will do since it should not be used (when named expressions are always fun expressions),

3. Evaluate the expression in the new environment,

4. Change the binding of the identifier (the box) to the result of this evaluation.

The resulting definition is:

Racket has another let relative for such cases of multiple-nested lets — let*. This form is a derived form — it is defined as a shorthand for using nested lets. The above is therefore exactly the same as this code:

This let* form can be read almost as a C/Java-ish kind of code:

The code can be simpler if we fold the evaluation into the set-box! (since value is used just there), and if use lookup to do the mutation — since this way there is no need to hold onto the box. This is a bit more expensive, but since the binding is guaranteed to be the first one in the environment, the addition is just one quick step. The only binding that we need is the one for the new environment, which we can do as an internal definition, leaving us with:

A complete rehacked version of FLANG with a rec binding follows. We can’t test rec easily since we have no conditionals, but you can at least verify that

is an infinite loop.