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 subtypeof T
then: (Listof S) subtypeof (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 (you’ll get an S
which is also a T
).
Such “containers” include functions that produce a value — for
example:
if: S subtypeof T
then: Q > S subtypeof 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 subtypeof S
then: S > Q subtypeof T > Q
To see why this is right, use Number
and Integer
for S
and T
:
if: Integer subtypeof Number
then: Number > Q subtypeof Integer > Q
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
if: S subtypeof T *and* T subtypeof S
then: (Boxof S) subtypeof (Boxof T)
which is actually:
if: S isthesametypeas T
then: (Boxof S) isthesametypeas (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.
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:
Readonly data types (sources) can be covariant; writeonly 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)
.
#lang pl
;; a type for a "readonly" box
(definetype (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 "writeonly" box
(definetype (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
(definetype (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:

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,

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

Evaluate the expression in the new environment,

Change the binding of the identifier (the box) to the result of this
evaluation.
The resulting definition is:
(: extendrec : 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 (extendrec id expr restenv)
(let ([newcell (box (NumV 42))])
(let ([newenv (Extend id newcell restenv)])
(let ([value (eval expr newenv)])
(setbox! newcell value)
newenv))))
Racket has another let
relative for such cases of multiplenested
let
s — let*
. This form is a derived form — it is defined as a
shorthand for using nested let
s. The above is therefore exactly the
same as this code:
(: extendrec : 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 (extendrec id expr restenv)
(let* ([newcell (box (NumV 42))]
[newenv (Extend id newcell restenv)]
[value (eval expr newenv)])
(setbox! newcell value)
newenv))
This let*
form can be read almost as a C/Javaish 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 setbox!
(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:
(: extendrec : Symbol FLANG ENV > ENV)
(define (extendrec id expr restenv)
(define newenv (Extend id (box (NumV 42)) restenv))
(setbox! (lookup id newenv) (eval expr newenv))
newenv)
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
(run "{rec {f {fun {x} {call f x}}} {call f 0}}")
is an infinite loop.
▶#lang pl
(definetype 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])
(: parsesexpr : Sexpr > FLANG)
;; parses sexpressions into FLANGs
(define (parsesexpr 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 (parsesexpr named) (parsesexpr body))]
[(list 'rec (list (symbol: name) named) body)
(WRec name (parsesexpr named) (parsesexpr body))]
[(cons x more)
(error 'parsesexpr "bad `~s' syntax in ~s" x sexpr)])]
[(cons 'fun more)
(match sexpr
[(list 'fun (list (symbol: name)) body)
(Fun name (parsesexpr body))]
[else (error 'parsesexpr "bad `fun' syntax in ~s" sexpr)])]
[(list '+ lhs rhs) (Add (parsesexpr lhs) (parsesexpr rhs))]
[(list ' lhs rhs) (Sub (parsesexpr lhs) (parsesexpr rhs))]
[(list '* lhs rhs) (Mul (parsesexpr lhs) (parsesexpr rhs))]
[(list '/ lhs rhs) (Div (parsesexpr lhs) (parsesexpr rhs))]
[(list 'call fun arg)
(Call (parsesexpr fun) (parsesexpr arg))]
[else (error 'parsesexpr "bad syntax in ~s" sexpr)]))
(: parse : String > FLANG)
;; parses a string containing a FLANG expression to a FLANG AST
(define (parse str)
(parsesexpr (string>sexpr str)))
;; Types for environments, values, and a lookup function
(definetype ENV
[EmptyEnv]
[Extend Symbol (Boxof VAL) ENV])
(definetype 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 boxedval restenv)
(if (eq? id name) boxedval (lookup name restenv))]))
(: extendrec : 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 (extendrec id expr restenv)
(define newenv (Extend id (box (NumV 42)) restenv))
(setbox! (lookup id newenv) (eval expr newenv))
newenv)
(: 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 'arithop "expected a number, got: ~s" val)]))
(: arithop : (Number Number > Number) VAL VAL > VAL)
;; gets a Racket numeric binary operator, and uses it within a NumV
;; wrapper
(define (arithop 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) (arithop + (eval l env) (eval r env))]
[(Sub l r) (arithop  (eval l env) (eval r env))]
[(Mul l r) (arithop * (eval l env) (eval r env))]
[(Div l r) (arithop / (eval l env) (eval r env))]
[(With boundid namedexpr boundbody)
(eval boundbody
(Extend boundid (box (eval namedexpr env)) env))]
[(WRec boundid namedexpr boundbody)
(eval boundbody
(extendrec boundid namedexpr env))]
[(Id name) (unbox (lookup name env))]
[(Fun boundid boundbody)
(FunV boundid boundbody env)]
[(Call funexpr argexpr)
(let ([fval (eval funexpr env)])
(cases fval
[(FunV boundid boundbody fenv)
(eval boundbody
(Extend boundid (box (eval argexpr env)) fenv))]
[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 nonnumber: ~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:

return some bogus value,

return the value that was assigned,

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 = x1) ...
).
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
box
es). 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.