2010-02-12
- Types of Evaluators
- Feature Embedding
- Recursion, Recursion, Recursion
- Recursion without the Magic

========================================================================
>>> Types of Evaluators

What we did just now is implement lexical environments and closures in
the language we implement using lexical environments and closures in our
own language (Scheme)!

This is another example of embedding a feature of the host language in
the implemented language, an issue that we have already discussed.

There are many examples of this, even when the two languages involved
are different.  For example, if we have this bit in a C implementation
of Scheme:

  // Disclaimer: not real mzscheme code
  Scheme_Object *eval_and( int argc, Scheme_Object *argv[] )
  {
    Scheme_Object *tmp;
    if ( argc != 2 )
      signal_scheme_error("bad number of arguments");
    else if ( scheme_eval(argv[0]) != scheme_false &&
              (tmp = scheme_eval(argv[1])) != scheme_false )
      return tmp;
    else
      return scheme_false;
  }

then the special semantics of evaluating a Scheme `and' form is being
inherited from C's special treatment of `&&'.  You can see this by the
fact that if there is a bug in the C compiler, then it will propagate to
the resulting Scheme implementation too.

We have seen a few different implementations of evaluators that are
quite different in flavor.  They suggest the following taxonomy.

* A <<syntactic evaluator>> is one that uses its own language to
  represent only expressions of the evaluated language, implementing all
  the corresponding behavior explicitly.

* A <<meta evaluator>> is an evaluator that uses language features of
  its own language to directly implement behavior of the evaluated
  language.

While our substitution-based FLANG evaluator was close to being a
syntactic evaluator, we haven't written any purely syntactic evaluators
so far: we still relied on things like Scheme arithmetics etc.  The most
recent evaluator that we have studied, is distinctly a meta evaluator.

With a good match between the evaluated language and the implementation
language, writing a meta evaluator can be very easy.  With a bad match,
though, it can be very hard.  With a syntactic evaluator, implementing
each semantic feature will be somewhat hard, but in return you don't
have to worry as much about how well the implementation and the
evaluated languages match up.  In particular, if there is a particularly
strong mismatch between the implementation and the evaluated language,
it may take less effort to write a syntactic evaluator than a meta
evaluator.  As an exercise, we can build upon our latest evaluator to
remove the encapsulation of the evaluator's response in the VAL type.
The resulting evaluator is shown below.  This is a true meta evaluator:
it uses Scheme closures to implement FLANG closures, Scheme procedure
application for FLANG function application, Scheme numbers for FLANG
numbers, and Scheme arithmetic for FLANG arithmetic.  In fact, ignoring
some small syntactic differences between Scheme and FLANG, this latest
evaluator can be classified as something more specific than a meta
evaluator:

* A <<meta-circular evaluator>> is a meta evaluator in which the
  implementation and the evaluated languages are the same.

(Put differently, the trivial nature of the evaluator clues us in to the
deep connection between the two languages, whatever their syntactic
differences may be.)

========================================================================
>>> Feature Embedding

We saw that the difference between lazy evaluation and eager evaluation
is in the evaluation rules for `with' forms, function applications, etc:

  eval({with {x E1} E2}) = eval(E2[eval(E1)/x])

is eager, and

  eval({with {x E1} E2}) = eval(E2[E1/x])

is lazy.  But is the first rule *really* eager?  The fact is that the
only thing that makes it eager is the fact that our understanding of the
mathematical notation is eager -- if we were to take math as lazy, then
the description of the rule becomes a description of lazy evaluation.

Another way to look at this is -- take the piece of code that implements
this evaluation:

  (: eval : FLANG -> Number)
  ;; evaluates FLANG expressions by reducing them to numbers
  (define (eval expr)
    (cases expr
      ...
      [(With bound-id named-expr bound-body)
       (eval (subst bound-body
                    bound-id
                    (Num (eval named-expr))))]
      ...))

and the same question applies: is this really implementing eager
evaluation?  We know that this is indeed eager -- we can simply try it
and check that it is, but it is only eager because we are using an eager
language for the implementation!  If Scheme itself was a lazy language,
then our own code would evaluate in a lazy way, so the above
applications of the the `eval' and the `subst' functions would also be
lazy, making our evaluator lazy as well.

This is a general phenomena where some of the semantic features of the
language we use (math in the formal description, Scheme in our code)
gets *embedded* into the language we implement.

Here's another example -- consider the code that implements arithmetics:

  (: eval : FLANG -> Number)
  ;; evaluates FLANG expressions by reducing them to numbers
  (define (eval expr)
    (cases expr
      [(Num n) n]
      [(Add l r) (+ (eval l) (eval r))]
      ...))

what if it was written like this:

  FLANG eval(FLANG expr) {
    if (is_Num(expr))
      return num_of_Num(expr);
    else if (is_Add(expr))
      return eval(lhs_of_Add(expr)) + eval(rhs_of_Add(expr));
    else if ...
    ...
  }

Would it still implement unlimited integers and exact fractions?  That
depends on the language that was used to implement it: the above syntax
suggests C, C++, Java, or some other relative, which usually come with
limited integers and no exact fractions.  But this really depends on the
language -- even our own code has unlimited integers and exact rationals
only because our Scheme implementation has them.  If we were using a
Scheme that didn't have such features (such implementations do exist),
then our implemented language would absorb these (lack of) features too,
and its own numbers would be limited in just the same way.  (And this
includes the syntax for numbers, which we embedded intentionally, like
the syntax for identifiers).

The bottom line is that we should be aware of such issues, and be very
careful when we talk about semantics.  Even the language that we use to
communicate (semi-formal logic) can mean different things.

========================================================================

Aside: read "Reflections on Trusting Trust" by Ken Thompson

  http://pl.barzilay.org/reflections-on-trusting-trust.pdf

(You can skip to the "Stage II" part to get to the interesting stuff.)

========================================================================

Here is yet another variation of our evaluator that is even closer to a
meta-circular evaluator.  It uses Scheme values directly to implement
values, so arithmetic operations become straightforward.  Note
especially how the case for function application is similar to
arithmetics: a FLANG function application translates to a Scheme
function application.  In both cases (applications and arithmetics) we
don't even check the objects since they are simple Scheme objects -- if
our Scheme implementation happens to have some meaning for arithmetics
with functions, or for applying numbers, then we will inherit the same
semantics in our language.  This means that we now specify less behavior
and fall back more often on what Scheme does.

We use Scheme values with this type definition:

  (define-type VAL = (U Number (VAL -> VAL)))

And the evaluation function can now be:

  (: eval : FLANG ENV -> VAL)
  ;; evaluates FLANG expressions by reducing them to values
  (define (eval expr env)
    (cases expr
      [(Num n) n]                 ;*** return the actual number
      [(Add l r) (+ (eval l env) (eval r env))]
      [(Sub l r) (- (eval l env) (eval r env))]
      [(Mul l r) (* (eval l env) (eval r env))]
      [(Div l r) (/ (eval l env) (eval r env))]
      [(With bound-id named-expr bound-body)
       (eval bound-body
             (Extend bound-id (eval named-expr env) env))]
      [(Id name) (lookup name env)]
      [(Fun bound-id bound-body)
       (lambda: ([arg-val : VAL]) ;*** return the scheme function
         (eval bound-body (Extend bound-id arg-val env)))]
      [(Call fun-expr arg-expr)
       ((eval fun-expr env)       ;*** trivial like the arithmetics!
        (eval arg-expr env))]))

Note how the arithmetics implementation is simple -- it's a direct
translation of the FLANG syntax to Scheme operations, and since we don't
check the inputs to the Scheme operations, we let Scheme throw type
errors for us.  Note also how function application is just like the
arithmetic operations: a FLANG application is directly translated to a
Scheme application.

However, this does not work quite as simply in typed scheme.  The whole
point of typechecking is that we never run into type errors -- so we
cannot throw back on Scheme errors since code that might produce them is
forbidden!  A way around this is to perform explicit checks that
guarantee that Scheme cannot run into type errors.  We do this with the
following two helpers that are defined inside `eval':

    (: evalN : FLANG -> Number)
    (define (evalN e)
      (let ([n (eval e env)])
        (if (number? n)
          n
          (error 'eval "got a non-number: ~s" n))))
    (: evalF : FLANG -> (VAL -> VAL))
    (define (evalF e)
      (let ([f (eval e env)])
        (if (procedure? f)
          f
          (error 'eval "got a non-function: ~s" f))))

Note that typed scheme is "smart enough" to figure out that in `evalF'
the result of the recursive evaluation is either Number or (VAL -> VAL);
and since the `if' throws out numbers, we're left with (VAL -> VAL)
functions, not just any function.

  ----------------------------------------------------------------------
  #lang pl

  (define-type FLANG
    [Num  (n Number)]
    [Add  (lhs FLANG) (rhs FLANG)]
    [Sub  (lhs FLANG) (rhs FLANG)]
    [Mul  (lhs FLANG) (rhs FLANG)]
    [Div  (lhs FLANG) (rhs FLANG)]
    [Id   (name Symbol)]
    [With (name Symbol) (named FLANG) (body FLANG)]
    [Fun  (name Symbol) (body FLANG)]
    [Call (fun-expr FLANG) (arg-expr FLANG)])

  (: parse-sexpr : Sexpr -> FLANG)
  ;; to convert s-expressions into FLANGs
  (define (parse-sexpr sexpr)
    (match sexpr
      [(number: n)    (Num n)]
      [(symbol: name) (Id name)]
      [(cons 'with more)
       (match sexpr
         [(list 'with (list (symbol: name) named) body)
          (With name (parse-sexpr named) (parse-sexpr body))]
         [else (error 'parse-sexpr "bad `with' syntax in ~s" sexpr)])]
      [(cons 'fun more)
       (match sexpr
         [(list 'fun (list (symbol: name)) body)
          (Fun name (parse-sexpr body))]
         [else (error 'parse-sexpr "bad `fun' syntax in ~s" sexpr)])]
      [(list '+ lhs rhs) (Add (parse-sexpr lhs) (parse-sexpr rhs))]
      [(list '- lhs rhs) (Sub (parse-sexpr lhs) (parse-sexpr rhs))]
      [(list '* lhs rhs) (Mul (parse-sexpr lhs) (parse-sexpr rhs))]
      [(list '/ lhs rhs) (Div (parse-sexpr lhs) (parse-sexpr rhs))]
      [(list 'call fun arg) (Call (parse-sexpr fun) (parse-sexpr arg))]
      [else (error 'parse-sexpr "bad syntax in ~s" sexpr)]))

  (: parse : String -> FLANG)
  ;; parses a string containing a FLANG expression to a FLANG AST
  (define (parse str)
    (parse-sexpr (string->sexpr str)))

  ;; Types for environments, values, and a lookup function

  ;; Values are plain Scheme values, no new VAL wrapper;
  ;; (but note that this is a recursive definition)
  (define-type VAL = (U Number (VAL -> VAL)))

  ;; Define a type for functional environments
  (define-type ENV = (Symbol -> VAL))

  (: EmptyEnv : -> ENV)
  (define (EmptyEnv)
    (lambda (id) (error 'lookup "no binding for ~s" id)))

  (: Extend : Symbol VAL ENV -> ENV)
  (define (Extend id v rest-env)
    (lambda (name)
      (if (eq? name id)
        v
        (rest-env name))))

  (: lookup : Symbol ENV -> VAL)
  (define (lookup name env)
    (env name))

  (: eval : FLANG ENV -> VAL)
  ;; evaluates FLANG expressions by reducing them to values
  (define (eval expr env)
    (: evalN : (FLANG -> Number))
    (define (evalN e)
      (let ([n (eval e env)])
        (if (number? n)
          n
          (error 'eval "got a non-number: ~s" n))))
    (: evalF : (FLANG -> (VAL -> VAL)))
    (define (evalF e)
      (let ([f (eval e env)])
        (if (procedure? f)
          f
          (error 'eval "got a non-function: ~s" f))))
    (cases expr
      [(Num n) n]
      [(Add l r) (+ (evalN l) (evalN r))]
      [(Sub l r) (- (evalN l) (evalN r))]
      [(Mul l r) (* (evalN l) (evalN r))]
      [(Div l r) (/ (evalN l) (evalN r))]
      [(With bound-id named-expr bound-body)
       (eval bound-body
             (Extend bound-id (eval named-expr env) env))]
      [(Id name) (lookup name env)]
      [(Fun bound-id bound-body)
       (lambda: ([arg-val : VAL])
         (eval bound-body (Extend bound-id arg-val env)))]
      [(Call fun-expr arg-expr)
       ((evalF fun-expr)
        (eval arg-expr env))]))

  (: run : (String -> VAL)) ; no need to convert VALs to numbers
  ;; evaluate a FLANG program contained in a string
  (define (run str)
    (eval (parse str) (EmptyEnv)))

  ;; tests
  (test (run "{call {fun {x} {+ x 1}} 4}")
        => 5)
  (test (run "{with {add3 {fun {x} {+ x 3}}}
                {call add3 1}}")
        => 4)
  (test (run "{with {add3 {fun {x} {+ x 3}}}
                {with {add1 {fun {x} {+ x 1}}}
                  {with {x 3}
                    {call add1 {call add3 x}}}}}")
        => 7)
  (test (run "{with {identity {fun {x} x}}
                {with {foo {fun {x} {+ x 1}}}
                  {call {call identity foo} 123}}}")
        => 124)
  (test (run "{with {x 3}
                {with {f {fun {y} {+ x y}}}
                  {with {x 5}
                    {call f 4}}}}")
        => 7)
  (test (run "{call {with {x 3}
                      {fun {y} {+ x y}}}
                    4}")
        => 7)
  (test (run "{call {call {fun {x} {call x 1}}
                          {fun {x} {fun {y} {+ x y}}}}
                    123}")
        => 124)
  ----------------------------------------------------------------------

========================================================================
>>> Recursion, Recursion, Recursion

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) Scheme -- 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:

  #lang pl broken
  (define (fact n)
    (if (zero? n) 1 (* n (fact (- n 1)))))
  (fact 5)

In our language, this translation would also not work (assuming we have
`if' etc):

  {with {fact {fun {n}
                {if {= n 0} 1 {* n {fact {- n 1}}}}}}
    {call fact 5}}

And similarly, in plain scheme this won't work if `let' is the only tool
you use to create bindings:

  (let ([fact (lambda (n)
                (if (zero? n) 1 (* n (fact (- n 1)))))])
    (fact 5))

In the broken-scope language, the `define' form is more similar to a
mathematical definition.  For example, when we write:

  (define (F x) x)
  (define (G y) (F y))
  (G F)

it is actually shorthand for

  (define F (lambda (x) x))
  (define G (lambda (y) (F y)))
  (G F)

and this can go on, until we get to the actual code that we wrote:

  ((lambda (y) ((lambda (x) x) y)) (lambda (x) x))

This means that the above `fact' definition is similar to writing:

  fact := (lambda (n)
            (if (zero? n) 1 (* n (fact (- n 1)))))
  (fact 5)

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 `:=')

  fact = (lambda (n)
           (if (zero? n) 1 (* n (fact (- n 1)))))

and find a solution which will be a value for `fact' that makes this
true.

If you look at the Scheme evaluation rules handout on the web page, you
will see that this problem is related to the way that we introduced the
Scheme `define': there is a hand-wavy explanation that talks about
*knowing* things.

The big question is: can we define recursive functions without Scheme's
magical `define' form?

(Note: This question is a little different than the question of
implementing recursion in our language -- in the Scheme 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 Scheme without
Scheme's magical definition forms?" or "can we get recursion in our
interpreter without mutation?".)

========================================================================
>>> Recursion without the Magic

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

  #lang pl dynamic
  (let ([fact (lambda (n)
                (if (zero? n) 1 (* n (fact (- n 1)))))])
    (fact 5))

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

  (define (fact self n)  ;***
    (if (zero? n) 1 (* n (self (- n 1)))))
  (fact fact 5)          ;***

except that now the recursive call should still send itself along:

  (define (fact self n)
    (if (zero? n) 1 (* n (self self (- n 1))))) ;***
  (fact fact 5)

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

  (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))

The first step in resolving this problem is to curry the `fact'
definition.

  (define (fact self)                  ;***
    (lambda (n)                        ;***
      (if (zero? n)
        1
        (* n ((self self) (- n 1)))))) ;***
  ((fact fact) 5)                      ;***

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.

  (define (make-fact self)             ;***
    (lambda (n)
      (if (zero? n) 1 (* n ((self self) (- n 1))))))
  (define fact (make-fact make-fact))  ;***
  (fact 5)                             ;***

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:

  (define (make-fact self)
    (lambda (n)
      (let ([fact (self self)])       ;***
        (if (zero? n)
          1
          (* n (fact (- n 1)))))))    ;***
  (define fact (make-fact make-fact))
  (fact 5)

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:

  (define (make-fact self)
    (let ([fact (self self)])  ;***
      (lambda (n)              ;***
        (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define fact (make-fact make-fact))
  (fact 5)

But the problem is that this gets us into an infinite loop because we're
trying to evaluate "(self self)" too early.  In fact, if we ignore the
body of the `let' and other details, we basically do this:

  (define (make-fact self) (self self)) (make-fact make-fact)
  --reduce-sugar-->
  (define make-fact (lambda (self) (self self))) (make-fact make-fact)
  --replace-definition-->
  ((lambda (self) (self self)) (lambda (self) (self self)))
  --rename-identifiers-->
  ((lambda (x) (x x)) (lambda (x) (x x)))

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 function as `add1', 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:

  (define (make-fact self)
    (let ([fact (lambda (n) ((self self) n))]) ;***
      (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define fact (make-fact make-fact))
  (fact 5)

Continuing from here -- we know that

  (let ([x v]) e)  is the same as  ((lambda (x) e) v)

(remember how we derived `fun' from a `with'), so we can turn that `let'
into the equivalent function application form:

  (define (make-fact self)
    ((lambda (fact)                    ;***
       (lambda (n) (if (zero? n) 1 (* n (fact (- n 1))))))
     (lambda (n) ((self self) n))))    ;***
  (define fact (make-fact make-fact))
  (fact 5)

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-core':

  (define fact-core                   ;***
    (lambda (fact)
      (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define (make-fact self)
    (fact-core                        ;***
     (lambda (n) ((self self) n))))
  (define fact (make-fact make-fact))
  (fact 5)

We can now proceed by moving the (make-fact make-fact) self-application
into its own function which is what creates the real factorial:

  (define fact-core
    (lambda (fact)
      (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define (make-fact self)
    (fact-core
     (lambda (n) ((self self) n))))
  (define (make-real-fact) (make-fact make-fact)) ;***
  (define fact (make-real-fact))                  ;***
  (fact 5)

Rewrite the `make-fact' definition using an explicit `lambda':

  (define fact-core
    (lambda (fact)
      (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define make-fact                     ;***
    (lambda (self)                      ;***
      (fact-core
       (lambda (n) ((self self) n)))))
  (define (make-real-fact) (make-fact make-fact))
  (define fact (make-real-fact))
  (fact 5)

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:

  (define fact-core
    (lambda (fact)
      (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define (make-real-fact)
    (let ([make (lambda (self)                      ;***
                  (fact-core                        ;***
                   (lambda (n) ((self self) n))))]) ;***
      (make make)))
  (define fact (make-real-fact))
  (fact 5)

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

  (define fact-core
    (lambda (fact)
      (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
  (define (make-recursive core)             ;***
    (let ([make (lambda (self)
                  (core                     ;***
                   (lambda (n) ((self self) n))))])
      (make make)))
  (define fact (make-recursive fact-core))  ;***
  (fact 5)

We're almost done now -- there's no real need for a separate `fact-core'
definition, just use the value for the definition of `face':

  (define (make-recursive core)
    (let ([make (lambda (self)
                  (core
                   (lambda (n) ((self self) n))))])
      (make make)))
  (define fact
    (make-recursive
     (lambda (fact)                                          ;***
       (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))) ;***
  (fact 5)

turn the `let' into a function form:

  (define (make-recursive core)
    ((lambda (make) (make make))              ;***
     (lambda (self)                           ;***
       (core (lambda (n) ((self self) n)))))) ;***
  (define fact
    (make-recursive
     (lambda (fact)
       (lambda (n) (if (zero? n) 1 (* n (fact (- n 1))))))))
  (fact 5)

do some renamings to make things simpler -- `make' and `self' turn to
`x', and `core' to `f':

  (define (make-recursive f)                   ;***
    ((lambda (x) (x x))                        ;***
     (lambda (x) (f (lambda (n) ((x x) n)))))) ;***
  (define fact
    (make-recursive
     (lambda (fact)
       (lambda (n) (if (zero? n) 1 (* n (fact (- n 1))))))))
  (fact 5)

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

  (define (make-recursive f)
    ((lambda (x) (f (lambda (n) ((x x) n))))   ;***
     (lambda (x) (f (lambda (n) ((x x) n)))))) ;***
  (define fact
    (make-recursive
     (lambda (fact)
       (lambda (n) (if (zero? n) 1 (* n (fact (- n 1))))))))
  (fact 5)

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:

  #lang pl broken
  (define (make-recursive f)
    ((lambda (x) (f (lambda (n) ((x x) n))))
     (lambda (x) (f (lambda (n) ((x x) n))))))
  (define fact
    (make-recursive
     (lambda (fact)
       (lambda (n) (if (zero? n) 1 (* n (fact (- n 1))))))))
  (fact 5)
  (define fib
    (make-recursive
     (lambda (fib)
       (lambda (n) (if (<= n 1) n (+ (fib (- n 1)) (fib (- n 2))))))))
  (fib 8)
  (define length
    (make-recursive
     (lambda (length)
       (lambda (l) (if (null? l) 0 (+ (length (cdr l)) 1))))))
  (length '(x y z))

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:

  (rewrite (define/rec (f x) E)
        => (define f (make-recursive (lambda (f) (lambda (x) E)))))

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

  #lang pl broken
  (define (make-recursive f)
    ((lambda (x) (f (lambda (n) ((x x) n))))
     (lambda (x) (f (lambda (n) ((x x) n))))))
  (rewrite (define/rec (f x) E)
        => (define f (make-recursive (lambda (f) (lambda (x) E)))))
  ;; examples
  (define/rec (fact n) (if (zero? n) 1 (* n (fact (- n 1)))))
  (fact 5)
  (define/rec (fib n) (if (<= n 1) n (+ (fib (- n 1)) (fib (- n 2)))))
  (fib 8)
  (define/rec (length l) (if (null? l) 0 (+ (length (cdr l)) 1)))
  (length '(x y z))

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,

  (make-recursive (lambda (f) (lambda (x) f)))

is a function that *returns* itself rather than calling itself.  Using
the rewrite rule, this would be:

  (define/rec (f x) f)

which is the same as:

  (define (f x) f)

in plain Scheme.

========================================================================