Implementing define-type + cases in Schlac

Another interesting way to implement lists follows the pattern matching approach, where both pairs and the null value are represented by a function that serves as a kind of a match dispatcher. This function takes in two inputs — if it is the representation of null then it will return the first input, and if it is a pair, then it will apply the second input on the two parts of the pair. This is implemented as follows (with type comments to make it clear):

This might seem awkward, but it follows the intended use of pairs and null as a match-like construct. Here is an example, with the equivalent Racket code on the side:

In fact, it’s easy to implement our selectors and predicate using this:

The same approach can be used to define any kind of new data type in a way that looks like our own define-type definitions. For example, consider a much-simplified definition of the AE type we’ve seen early in the semester, and a matching eval definition as an example for using cases:

We can follow the above approach now to write Schlac code that more than being equivalent, is also very similar in nature. Note that the type definition is replaced by two definitions for the two constructors:

We can even take this further: the translations from define-type and cases are mechanical enough that we could implement them almost exactly via rewrites (there are a subtle change in that we’re list field names rather than types):

And using that, an evluator is simple:

Recursive Environments

PLAI §11.5

What we really need for recursion, is a special kind of an environment, one that can refer to itself. So instead of doing (note: calls removed for readability):

which does not work for the usual reasons, we want to use some

that will do the necessary magic.

One way to achieve this is using the Y combinator as we have seen — a kind of a “constructor” for recursive functions. We can do that in a similar way to the rewrite rule that we have seen in Schlac — translate the above expression to:

or even:

Now, we will see how it can be used in our code to implement a recursive environment.

If we look at what with does in

then we can say that to evaluate this expression, we evaluate the body expression in an extended environment that contains fact, even if a bogus one that is good for 0 only — the new environment is created with something like this:

so we can take this whole thing as an operation over env

This gives us the first-level fact. But fact itself is still undefined in env, so it cannot call itself. We can try this:

but that still doesn’t work, and it will never work no matter how far we go:

What we really want is infinity: a place where add-fact works and the result is the same as what we’ve started with — we want to create a “magical” environment that makes this possible:

which basically gives us the illusion of being at the infinity point. This magic-env thing is exactly the fixed-point of the add-fact operation. We can use:

and following the main property of the Y combinator, we know that:

What does all this mean? It means that if we have a fixed-point operator at the level of the implementation of our environments, then we can use it to implement a recursive binder. In our case, this means that a fixpoint in Racket can be used to implement a recursive language. But we have that — Racket does have recursive functions, so we should be able to use that to implement our recursive binder.

There are two ways that make it possible to write recursive functions in Racket. One is to define a function, and use its name to do a recursive call — using the Racket formal rules, we can see that we said that we mark that we now know that a variable is bound to a value. This is essentially a side-effect — we modify what we know, which corresponds to modifying the global environment. The second way is a new form: letrec. This form is similar to let, except that the scope that is established includes the named expressions — it is exactly what we want rec to do. A third way is using recursive local definitions, but that is equivalent to using letrec, more on this soon.

Recursion: Racket’s letrec

So we want to add recursion to our language, practically. We already know that Racket makes it possible to write recursive functions, which is possible because of the way it implements its “global environment”: our evaluator can only extend an environment, while Racket modifies its global environment. This means that whenever a function is defined in the global environment, the resulting closure will have it as its environment “pointer”, but the global environment was not extended — it stays the same, and was just modified with one additional binding.

But Racket has another, a bit more organized way of using recursion: there is a special local-binding construct that is similar to let, but allows a function to refer to itself. It is called letrec:

Some people may remember that there was a third way for creating recursive functions: using local definition in function bodies. For example, we have seen things like:

This looks like the same kind of environment magic that happens with a global define — but actually, Racket defines the meaning of internal definitions using letrec — so the above code is exactly the same as:

The scoping rules for a letrec is that the scope of the bound name covers both the body and the named expression. Furthermore, multiple names can be bound to multiple expressions, and the scope of each name covers all named expression as well as the body. This makes it easy to define mutually recursive functions, such as:

But it is not a required functionality — it could be done with a single recursive binding that contains several functions:

This is basically the same problem we face if we want to use the Y combinator for mutually recursive bindings. The above solution is inconvenient, but it can be improved using more lets to have easier name access. For example:

Implementing Recursion using letrec

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 Racket’s 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 TR’s 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:

Now, the 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:

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

2. Second, a related problem — what happens if we try to run this:

   {rec {x x} x}

   ? 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:

   (eval (Id 'x) the-new-env)

   so we look up the value:

   (lookup 'x the-new-env)

   which is:

   (the-new-env 'x)

   which goes into the function which implements this environment, there we see that name is the same as name1, so we return:

   (eval expr rec-env)

   but the 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 newly-created environment:

This runs into an interesting type error, which complains about possibly getting some 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 meaning of:

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.