PL: Lecture #14  Tuesday, February 18th
(text)

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:

(define my-thing (box 7))

the value is retrieved with the `unbox’ function,

(* 6 (unbox my-thing))

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

(set-box! my-thing 17)
(* 6 (unbox my-thing))

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:

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:

#lang pl untyped
(define foo (list 1 (box 3)))
(set-box! (second foo) foo)

and we get a circular value. (Note how it is printed.) And with types:

#lang pl
(: foo : (List Number (Boxof Any)))
(define foo (list 1 (box 3)))
(set-box! (second foo) foo)

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

(unbox (second foo))

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

(second (unbox (second foo)))

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:

#lang pl
(: foo : (Rec this (List Number (Boxof (U #f this)))))
(define foo (list 1 (box #f)))
(set-box! (second foo) foo)

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:

#lang pl
(: foo : (Listof Number) -> Number)
(define (foo l)
  (first l))
(: bar : Integer -> Number)
(define (bar x)
  (foo (list x)))

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:

(: bar : Integer -> Integer)

we get a type error since Number is not a subtype of Integer. So subtypes are required to “go up” on the input side and “down” 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:

#lang pl
(: foo : (Boxof Number) -> Number)
(define (foo b)
  (unbox b))
(: bar : Integer -> Number)
(define (bar x)
  (: b : (Boxof Integer))
  (define b (box x))
  (foo b))

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:

(define (bar x)
  (foo (box x)))

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.

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:

if:          S  subtype-of          T
then: (Listof S)  subtype-of  (Listof T)

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. Such “containers” include functions that produce a value — for example:

if:        S  subtype-of      T
then:  Q -> S  subtype-of  Q -> T

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:

if:    T      subtype-of  S
then:  S -> Q  subtype-of  T -> Q

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

if:    Integer      subtype-of  Number
then:  Number -> Q  subtype-of  Integer -> Q

so — if you expect a function that takes a number is a subtype of one that takes an integer; 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, but on the input side things are flipped — a bigger input type means a more constrained function.

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

if:    S subtype-of T  *and*  T subtype-of S
then:  (Boxof S) subtype-of (Boxof T)

which is actually:

if:          S  is-the-same-type-as        T
then:  (Boxof S)  is-the-same-type-as  (Boxof T)

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.

(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 a 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.)

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

#lang pl

;; a type for a "read-only" box
(define-type (Boxof/R A) = (-> A))
;; Boxof/R constructor
(: box/r : (All (A) A -> (Boxof/R A)))
(define (box/r x) (lambda () x))
;; we can see that (Boxof/R T1) is a subtype of (Boxof/R T2)
;; if T1 is a subtype of T2 (this is not surprising, since
;; these boxes are similar to any other container, like lists):
(: foo1 : Integer -> (Boxof/R Integer))
(define (foo1 b) (box/r b))
(: bar1 : (Boxof/R Number) -> Number)
(define (bar1 b) (b))
(test (bar1 (foo1 123)) => 123)

;; a type for a "write-only" box
(define-type (Boxof/W A) = (A -> Void))
;; Boxof/W constructor
(: box/w : (All (A) A -> (Boxof/W A)))
(define (box/w x) (lambda (new) (set! x new)))
;; in contrast to the above, (Boxof/W T1) is a subtype of
;; (Boxof/W T2) if T2 is a subtype of T1, *not* the other way
;; (and note how this is related to A being on the *left* side
;; of the arrow in the `Boxof/W' type):
(: foo2 : Number -> (Boxof/W Number))
(define (foo2 b) (box/w b))
(: bar2 : (Boxof/W Integer) Integer -> Void)
(define (bar2 b new) (b new))
(test (bar2 (foo2 123) 456))

;; combining the above two into a type for a "read/write" box
(define-type (Boxof/RW A) = (A -> A))
;; Boxof/RW constructor
(: box/rw : (All (A) A -> (Boxof/RW A)))
(define (box/rw x) (lambda (new) (let ([old x]) (set! x new) old)))
;; this combines the above two: `A' appears on both sides of the
;; arrow, so (Boxof/RW T1) is a subtype of (Boxof/RW T2) if T1
;; is a subtype of T2 (because there's an A on the right) *and*
;; if T2 is a subtype of T1 (because there's another A on the
;; left) -- and that can happen only when T1 and T2 are the same
;; type.  So this is a type error:
;;  (: foo3 : Integer -> (Boxof/RW Integer))
;;  (define (foo3 b) (box/rw b))
;;  (: bar3 : (Boxof/RW Number) Number -> Number)
;;  (define (bar3 b new) (b new))
;;  (test (bar3 (foo3 123) 456) => 123)
;;  ** Expected (Number -> Number), but got (Integer -> Integer)
;; And this a type error too:
;;  (: foo3 : Number -> (Boxof/RW Number))
;;  (define (foo3 b) (box/rw b))
;;  (: bar3 : (Boxof/RW Integer) Integer -> Integer)
;;  (define (bar3 b new) (b new))
;;  (test (bar3 (foo3 123) 456) => 123)
;;  ** Expected (Integer -> Integer), but got (Number -> Number)
;; The two types must be the same for this to work:
(: foo3 : Integer -> (Boxof/RW Integer))
(define (foo3 b) (box/rw b))
(: bar3 : (Boxof/RW Integer) Integer -> Integer)
(define (bar3 b new) (b new))
(test (bar3 (foo3 123) 456) => 123)

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:

(: extend-rec : Symbol FLANG ENV -> ENV)
;; extend an environment with a new binding that is the result of
;; evaluating an expression in the same environment as the extended
;; result
(define (extend-rec id expr rest-env)
  (let ([new-cell (box (NumV 42))])
    (let ([new-env (Extend id new-cell rest-env)])
      (let ([value (eval expr new-env)])
        (set-box! new-cell value)
        new-env))))

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:

(: extend-rec : Symbol FLANG ENV -> ENV)
;; extend an environment with a new binding that is the result of
;; evaluating an expression in the same environment as the extended
;; result
(define (extend-rec id expr rest-env)
  (let* ([new-cell (box (NumV 42))]
        [new-env  (Extend id new-cell rest-env)]
        [value    (eval expr new-env)])
    (set-box! new-cell value)
    new-env))

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

fun extend_rec(id, expr, rest_env) {
  new_cell  = new NumV(42);
  new_env  = Extend(id, new_cell, rest_env);
  value    = eval(expr, new_env);
  *new_cell = value;
  return new_env;
}

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:

(: extend-rec : Symbol FLANG ENV -> ENV)
(define (extend-rec id expr rest-env)
  (define new-env (Extend id (box (NumV 42)) rest-env))
  (set-box! (lookup id new-env) (eval expr new-env))
  new-env)

A complete rehacked version of FLANG with a rec binding follows:

#lang pl

(define-type FLANG
  [Num  Number]
  [Add  FLANG FLANG]
  [Sub  FLANG FLANG]
  [Mul  FLANG FLANG]
  [Div  FLANG FLANG]
  [Id  Symbol]
  [With Symbol FLANG FLANG]
  [WRec Symbol FLANG FLANG]
  [Fun  Symbol FLANG]
  [Call FLANG FLANG])

(: parse-sexpr : Sexpr -> FLANG)
;; parses s-expressions into FLANGs
(define (parse-sexpr sexpr)
  (match sexpr
    [(number: n)    (Num n)]
    [(symbol: name) (Id name)]
    [(cons (or 'with 'rec) more)
    (match sexpr
      [(list 'with (list (symbol: name) named) body)
        (With name (parse-sexpr named) (parse-sexpr body))]
      [(list 'rec (list (symbol: name) named) body)
        (WRec name (parse-sexpr named) (parse-sexpr body))]
      [(cons x more)
        (error 'parse-sexpr "bad `~s' syntax in ~s" x 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

(define-type ENV
  [EmptyEnv]
  [Extend Symbol (Boxof VAL) ENV])

(define-type VAL
  [NumV Number]
  [FunV Symbol FLANG ENV])

(: lookup : Symbol ENV -> (Boxof VAL))
;; lookup a symbol in an environment, return its value or throw an
;; error if it isn't bound
(define (lookup name env)
  (cases env
    [(EmptyEnv) (error 'lookup "no binding for ~s" name)]
    [(Extend id boxed-val rest-env)
    (if (eq? id name) boxed-val (lookup name rest-env))]))

(: extend-rec : Symbol FLANG ENV -> ENV)
;; extend an environment with a new binding that is the result of
;; evaluating an expression in the same environment as the extended
;; result
(define (extend-rec id expr rest-env)
  (define new-env (Extend id (box (NumV 42)) rest-env))
  (set-box! (lookup id new-env) (eval expr new-env))
  new-env)

(: NumV->number : VAL -> Number)
;; convert a FLANG runtime numeric value to a Racket one
(define (NumV->number val)
  (cases val
    [(NumV n) n]
    [else (error 'arith-op "expected a number, got: ~s" val)]))

(: arith-op : (Number Number -> Number) VAL VAL -> VAL)
;; gets a Racket numeric binary operator, and uses it within a NumV
;; wrapper
(define (arith-op op val1 val2)
  (NumV (op (NumV->number val1) (NumV->number val2))))

(: eval : FLANG ENV -> VAL)
;; evaluates FLANG expressions by reducing them to values
(define (eval expr env)
  (cases expr
    [(Num n) (NumV n)]
    [(Add l r) (arith-op + (eval l env) (eval r env))]
    [(Sub l r) (arith-op - (eval l env) (eval r env))]
    [(Mul l r) (arith-op * (eval l env) (eval r env))]
    [(Div l r) (arith-op / (eval l env) (eval r env))]
    [(With bound-id named-expr bound-body)
    (eval bound-body
          (Extend bound-id (box (eval named-expr env)) env))]
    [(WRec bound-id named-expr bound-body)
    (eval bound-body
          (extend-rec bound-id named-expr env))]
    [(Id name) (unbox (lookup name env))]
    [(Fun bound-id bound-body)
    (FunV bound-id bound-body env)]
    [(Call fun-expr arg-expr)
    (let ([fval (eval fun-expr env)])
      (cases fval
        [(FunV bound-id bound-body f-env)
          (eval bound-body
                (Extend bound-id (box (eval arg-expr env)) f-env))]
        [else (error 'eval "`call' expects a function, got: ~s"
                            fval)]))]))

(: run : String -> Number)
;; evaluate a FLANG program contained in a string
(define (run str)
  (let ([result (eval (parse str) (EmptyEnv))])
    (cases result
      [(NumV n) n]
      [else (error 'run "evaluation returned a non-number: ~s"
                  result)])))

;; 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 "{with {f {with {x 3} {fun {y} {+ x y}}}}
              {with {x 100}
                {call f 4}}}")
      => 7)
(test (run "{call {call {fun {x} {call x 1}}
                        {fun {x} {fun {y} {+ x y}}}}
                  123}")
      => 124)

Variable Mutation

PLAI §12 and PLAI §13 (different: adds boxes to the language)

PLAI §14 (that’s what we do)

The code that we now have implements recursion by changing bindings, and to make that possible we made environments hold boxes for all bindings, therefore bindings are all mutable now. We can use this to add more functionality to our evaluator, by allowing changing any variable — we can add a set! form:

{set! <id> <FLANG>}

to the evaluator that will modify the value of a variable. To implement this functionality, all we need to do is to use lookup to retrieve some box, then evaluate the expression and put the result in that box. The actual implementation is left as a homework exercise.

One thing that should be considered here is — all of the expressions in our language evaluate to some value, the question is what should be the value of a set! expression? There are three obvious choices:

  1. return some bogus value,

  2. return the value that was assigned,

  3. return the value that was previously in the box.

Each one of these has its own advantage — for example, C uses the second option to chain assignments (eg, x = y = 0) and to allow side effects where an expression is expected (eg, while (x = x-1) ...).

The third one is useful in cases where you might use the old value that is overwritten — for example, if C had this behavior, you could pop a value from a linked list using something like:

first(stack = rest(stack));

because the argument to first will be the old value of stack, before it changed to be its rest. You could also swap two variables in a single expression: x = y = x.

(Note that the expression x = x + 1 has the meaning of C’s ++x when option (2) is used, and x++ when option (3) is used.)

Racket chooses the first option, and we will do the same in our language. The advantage here is that you get no discounts, therefore you must be explicit about what values you want to return in situations where there is no obvious choice. This leads to more robust programs since you do not get other programmers that will rely on a feature of your code that you did not plan on.

In any case, the modification that introduces mutation is small, but it has a tremendous effect on our language: it was true for Racket, and it is true for FLANG. We have seen how mutation affects the language subset that we use, and in the extension of our FLANG the effect is even stronger: since any variable can change (no need for explicit boxes). In other words, a binding is not always the same — in can change as a result of a set! expression. Of course, we could extend our language with boxes (using Racket boxes to implement FLANG boxes), but that will be a little more verbose.

Note that Racket does have a set! form, and in addition, fields in structs can be made modifiable. However, we do not use any of these. At least not for now.

State and Environments

A quick example of how mutation can be used:

(define counter
  (let ([counter (box 0)])
    (lambda ()
      (set-box! counter (+ 1 (unbox counter)))
      (unbox counter))))

and compare that to:

(define (make-counter)
  (let ([counter (box 0)])
    (lambda ()
      (set-box! counter (+ 1 (unbox counter)))
      (unbox counter))))

It is a good idea if you follow the exact evaluation of

(define foo (make-counter))
(define bar (make-counter))

and see how both bindings have separate environment so each one gets its own private state. The equivalent code in the homework interpreter extended with set! doesn’t need boxes:

{with {make-counter
        {fun {}
          {with {counter 0}
            {fun {}
              {set! counter {+ counter 1}}
              counter}}}}
  {with {foo {call make-counter}}
    {with {bar {call make-counter}}
      ...}}}

(To see multiple values from a single expression you can extend the language with a list binding.) Note that we cannot describe this behavior with substitution rules! We now use the environments to make it possible to change bindings — so finally an environment is actually an environment rather than a substitution cache.

When you look at the above, note that we still use lexical scope — in fact, the local binding is actually a private state that nobody can access. For example, if we write this:

(define counter
  (let ([counter (box 0)])
    (lambda ()
      (set-box! counter (+ 1 (unbox counter)))
      (if (zero? (modulo (unbox counter) 4)) 'tock 'tick))))

then the resulting function that us bound to counter keeps a local integer state which no other code can access — you cannot modify it, reset it, or even know if it is really an integer that is used in there.

Implementing Objects with State

We have already seen how several pieces of information can be encapsulate in a Racket closure that keeps them all; now we can do a little more — we can actually have mutable state, which leads to a natural way to implement objects. For example:

(define (make-point x y)
  (let ([xb (box x)]
        [yb (box y)])
    (lambda (msg)
      (match msg
        ['getx (unbox xb)]
        ['gety (unbox yb)]
        ['incx (set-box! xb (add1 (unbox xb)))]))))

implements a constructor for point objects which keep two values and can move one of them. Note that the messages act as a form of methods, and that the values themselves are hidden and are accessible only through the interface that these messages make. For example, if these points correspond to some graphic object on the screen, we can easily incorporate a necessary screen update:

(define (make-point x y)
  (let ([xb (box x)]
        [yb (box y)])
    (lambda (msg)
      (match msg
        ['getx (unbox xb)]
        ['gety (unbox yb)]
        ['incx (set-box! xb (add1 (unbox xb)))
              (update-screen)]))))

and be sure that this is always done when the value changes — since there is no way to change the value except through this interface.

A more complete example would define functions that actually send these messages — here is a better implementation of a point object and the corresponding accessors and mutators:

(define (make-point x y)
  (let ([xb (box x)]
        [yb (box y)])
    (lambda (msg)
      (match msg
        ['getx (unbox xb)]
        ['gety (unbox yb)]
        [(list 'setx newx)
        (set-box! xb newx)
        (update-screen)]
        [(list 'sety newy)
        (set-box! yb newy)
        (update-screen)]))))
(define (point-x p) (p 'getx))
(define (point-y p) (p 'gety))
(define (set-point-x! p x) (p (list 'setx x)))
(define (set-point-y! p y) (p (list 'sety y)))

And a quick imitation of inheritance can be achieved using delegation to an instance of the super-class:

(define (make-colored-point x y color)
  (let ([p (make-point x y)])
    (lambda (msg)
      (match msg
        ['getcolor color]
        [else (p msg)]))))

You can see how all of these could come from some preprocessing of a more normal-looking class definition form, like:

(defclass point (x y)
  (public (getx) x)
  (public (gety) y)
  (public (setx new) (set! x newx))
  (public (setx new) (set! x newx)))

(defclass colored-point point (c)
  (public (getcolor) c))