There is one major feature that is still missing from our language: we
have no way to perform recursion (therefore no kind of loops). So far,
we could only use recursion when we had names. In FLANG, the only way
we can have names is through with which not good enough for recursion.
To discuss the issue of recursion, we switch to a “broken” version of
(untyped) Racket — one where a define has a different scoping rules:
the scope of the defined name does not cover the defined expression.
Specifically, in this language, this doesn’t work:
In our language, this translation would also not work (assuming we have
if etc):
And similarly, in plain Racket this won’t work if let is the only tool
you use to create bindings:
In the broken-scope language, the define form is more similar to a
mathematical definition. For example, when we write:
it is actually shorthand for
we can then replace defined names with their definitions:
and this can go on, until we get to the actual code that we wrote:
This means that the above fact definition is similar to writing:
which is not a well-formed definition — it is meaningless (this is a
formal use of the word “meaningless”). What we’d really want, is to
take the equation (using = instead of :=)
and find a solution which will be a value for fact that makes this
true.
If you look at the Racket evaluation rules handout on the web page, you
will see that this problem is related to the way that we introduced the
Racket define: there is a hand-wavy explanation that talks about
knowing things.
The big question is: can we define recursive functions without Racket’s
magical define form?
Note: This question is a little different than the question of implementing recursion in our language — in the Racket case we have no control over the implementation of the language. As it will eventually turn out, implementing recursion in our own language will be quite easy when we use mutation in a specific way. So the question that we’re now facing can be phrased as either “can we get recursion in Racket without Racket’s magical definition forms?” or “can we get recursion in our interpreter without mutation?”.
PLAI §22.4 (we go much deeper)
Note: This explanation is similar to the one you can find in “The Why of Y”, by Richard Gabriel.
To implement recursion without the define magic, we first make an
observation: this problem does not come up in a dynamically-scoped
language. Consider the let-version of the problem:
This works fine — because by the time we get to evaluate the body of
the function, fact is already bound to itself in the current dynamic
scope. (This is another reason why dynamic scope is perceived as a
convenient approach in new languages.)
Regardless, the problem that we have with lexical scope is still there,
but the way things work in a dynamic scope suggest a solution that we
can use now. Just like in the dynamic scope case, when fact is
called, it does have a value — the only problem is that this value is
inaccessible in the lexical scope of its body.
Instead of trying to get the value in via lexical scope, we can imitate
what happens in the dynamically scoped language by passing the fact
value to itself so it can call itself (going back to the original code
in the broken-scope language):
except that now the recursive call should still send itself along:
The problem is that this required rewriting calls to fact — both
outside and recursive calls inside. To make this an acceptable
solution, calls from both places should not change. Eventually, we
should be able to get a working fact definition that uses just
The first step in resolving this problem is to curry the fact
definition.
Now fact is no longer our factorial function — it’s a function that
constructs it. So call it make-fact, and bind fact to the actual
factorial function.
We can try to do the same thing in the body of the factorial function:
instead of calling (self self), just bind fact to it:
This works fine, but if we consider our original goal, we need to get
that local fact binding outside of the (lambda (n) ...) — so we’re
left with a definition that uses the factorial expression as is. So,
swap the two lines:
But the problem is that this gets us into an infinite loop because we’re
trying to evaluate (self self) too ea(ge)rly. In fact, if we ignore
the body of the let and other details, we basically do this:
And this expression has an interesting property: it reduces to itself, so evaluating it gets stuck in an infinite loop.
So how do we solve this? Well, we know that (self self) should be
the same value that is the factorial function itself — so it must be a
one-argument function. If it’s such a function, we can use a value that
is equivalent, except that it will not get evaluated until it is needed,
when the function is called. The trick here is the observation that
(lambda (n) (add1 n)) is really the same as add1 (provided that
add1 is a one-argument function), except that the add1 part doesn’t
get evaluated until the function is called. Applying this trick to our
code produces a version that does not get stuck in the same infinite
loop:
Continuing from here — we know that
(remember how we derived fun from a with), so we can turn that let
into the equivalent function application form:
And note now that the (lambda (fact) …) expression is everything that
we need for a recursive definition of fact — it has the proper
factorial body with a plain recursive call. It’s almost like the usual
value that we’d want to define fact as, except that we still have to
abstract on the recursive value itself. So lets move this code into a
separate definition for fact-step:
We can now proceed by moving the (make-fact make-fact) self
application into its own function which is what creates the real
factorial:
Rewrite the make-fact definition using an explicit lambda:
and fold the functionality of make-fact and make-real-fact into a
single make-fact function by just using the value of make-fact
explicitly instead of through a definition:
We can now observe that make-real-fact has nothing that is specific to
factorial — we can make it take a “core function” as an argument:
and call it make-recursive:
We’re almost done now — there’s no real need for a separate
fact-step definition, just use the value for the definition of fact:
turn the let into a function form:
do some renamings to make things simpler — make and self turn to
x, and core to f:
or we can manually expand that first (lambda (x) (x x)) application to
make the symmetry more obvious (not really surprising because it started
with a let whose purpose was to do a self-application):
And we finally got what we were looking for: a general way to define
any recursive function without any magical define tricks. This also
work for other recursive functions:
A convenient tool that people often use on paper is to perform a kind of
a syntactic abstraction: “assume that whenever I write (twice foo) I
really meant to write (foo foo)”. This can often be done as plain
abstractions (that is, using functions), but in some cases — for
example, if we want to abstract over definitions — we just want such a
rewrite rule. (More on this towards the end of the course.) The
broken-scope language does provide such a tool — rewrite extends the
language with a rewrite rule. Using this, and our make-recursive, we
can make up a recursive definition form:
In other words, we’ve created our own “magical definition” form. The above code can now be written in almost the same way it is written in plain Racket:
Finally, note that make-recursive is limited to 1-argument functions only because of the protection from eager evaluation. In any case, it can be used in any way you want, for example,
is a function that returns itself rather than calling itself. Using the rewrite rule, this would be:
which is the same as:
in plain Racket.
make-recursiveAs in Racket, being able to express recursive functions is a fundamental property of the language. It means that we can have loops in our language, and that’s the essence of making a language powerful enough to be TM-equivalent — able to express undecidable problems, where we don’t know whether there is an answer or not.
The core of what makes this possible is the expression that we have seen in our derivation:
which reduces to itself, and therefore has no value: trying to evaluate it gets stuck in an infinite loop. (This expression is often called “Omega”.)
This is the key for creating a loop — we use it to make recursion
possible. Looking at our final make-recursive definition and ignoring
for a moment the “protection” that we need against being stuck
prematurely in an infinite loop:
we can see that this is almost the same as the Omega expression — the
only difference is that application of f. Indeed, this expression
(the result of (make-recursive F) for some F) reduces in a similar way
to Omega:
which means that the actual value of this expression is:
This definition would be sufficient if we had a lazy language, but to
get things working in a strict one we need to bring back the protection.
This makes things a little different — if we use (protect f) to be a
shorthand for the protection trick,
then we have:
which makes the (make-recursive F) evaluation reduce to
and this is still the same result (as long as F is a single-argument
function).
(Note that protect cannot be implemented as a plain function!)
Note: This explanation is similar to the one you can find in “The Little Schemer” called “(Y Y) Works!”, by Dan Friedman and Matthias Felleisen.
The explanation that we have now for how to derive the make-recursive
definition is fine — after all, we did manage to get it working. But
this explanation was done from a kind of an operational point of view:
we knew a certain trick that can make things work and we pushed things
around until we got it working like we wanted. Instead of doing this,
we can re-approach the problem from a more declarative point of view.
So, start again from the same broken code that we had (using the broken-scope language):
This is as broken as it was when we started: the occurrence of fact in
the body of the function is free, which means that this code is
meaningless. To avoid the compilation error that we get when we run
this code, we can substitute anything for that fact — it’s even
better to use a replacement that will lead to a runtime error:
This function will not work in a similar way to the original one — but
there is one case where it does work: when the input value is 0
(since then we do not reach the bogus application). We note this by
calling this function fact0:
Now that we have this function defined, we can use it to write fact1
which is the factorial function for arguments of 0 or 1:
And remember that this is actually just shorthand for:
We can continue in this way and write fact2 that will work for n<=2:
or, in full form:
If we continue this way, we will get the true factorial function, but the problem is that to handle any possible integer argument, it will have to be an infinite definition! Here is what it is supposed to look like:
The true factorial function is fact-infinity, with an infinite size.
So, we’re back at the original problem…
To help make things more concise, we can observe the repeated pattern in
the above, and extract a function that abstracts this pattern. This
function is the same as the fact-step that we have seen previously:
which is actually:
Do this a little differently — rewrite fact0 as:
Similarly, fact1 is written as:
and so on, until the real factorial, which is still infinite at this stage:
Now, look at that (lambda (mk) ...) — it is an infinite expression,
but for every actual application of the resulting factorial function we
only need a finite number of mk applications. We can guess how many,
and as soon as we hit an application of 777 we know that our guess is
too small. So instead of 777, we can try to use the maker function to
create and use the next.
To make things more explicit, here is the expression that is our
fact0, without the definition form:
This function has a very low guess — it works for 0, but with 1 it
will run into the 777 application. At this point, we want to somehow
invoke mk again to get the next level — and since 777 does get
applied, we can just replace it with mk:
The resulting function works just the same for an input of 0 because
it does not attempt a recursive call — but if we give it 1, then
instead of running into the error of applying 777:
we get to apply fact-step there:
and this is still wrong, because fact-step expects a function as an
input. To see what happens more clearly, write fact-step explicitly:
The problem is in what we’re going to pass into fact-step — its
fact argument will not be the factorial function, but the mk
function constructor. Renaming the fact argument as mk will make
this more obvious (but not change the meaning):
It should now be obvious that this application of mk will not work,
instead, we need to apply it on some function and then apply the
result on (- n 1). To get what we had before, we can use 777 as a
bogus function:
This will allow one recursive call — so the definition works for both
inputs of 0 and 1 — but not more. But that 777 is used as a
maker function now, so instead, we can just use mk itself again:
And this is a working version of the real factorial function, so make it into a (non-magical) definition:
But we’re not done — we “broke” into the factorial code to insert that
(mk mk) application — that’s why we dragged in the actual value of
fact-step. We now need to fix this. The expression on that last line
is close enough — it is (fact-step (mk mk)). So we can now try to
rewrite our fact as:
… and would fail in a familiar way! If it’s not familiar enough, just
rename all those mks as xs:
We’ve run into the eagerness of our language again, as we did before.
The solution is the same — the (x x) is the factorial function, so
protect it as we did before, and we have a working version:
The rest should not be surprising now… Abstract the recursive making
bit in a new make-recursive function:
and now we can do the first reduction inside make-recursive and write
the fact-step expression explicitly:
and this is the same code we had before.