Lecture 6: The Substitution Model of Evaluation

In this lecture, we examine more closely how OCaml programs are evaluated. We build a more formal and precise description of the evaluation process. This is a model of evaluation based on the basic notion of substitution, in which variable names are replaced by values that they are bound to. This corresponds to the mathematical notion that two equal things are interchangeable.

A tricky example

What is the value of the following expression? (Note that this is not just a definition of a function. It binds two names evil and dummy to functions and then applies evil to three arguments, returning the value of that expression. The names evil and dummy are bound only in the body and not at top level.)


We can see that the function evil calls itself recursively, and the result of the function is the result when it is called with n = 1. But what are the values returned by the applications of the functions f, f1 and f2? To understand what those values are, we need to better understand the OCaml evaluation model, and how variable names like n are bound.

Evaluation

The OCaml prompt lets you type either a term or a declaration that binds a variable to the value of a term. It evaluates the term to produce a value, which is a term that does not need any further evaluation. We can define values as a syntactic class too. Values include not only constants, but tuples of values, variant constructors applied to values, and functions.

Running an OCaml program is just evaluating a term. What happens when we evaluate a term? In an imperative (non-functional) language like Java, we sometimes imagine that there is an idea of a "current statement" that is executing. This isn't a very good model for OCaml; it is better to think of OCaml programs as being evaluated in the same way that you would evaluate a mathematical expression. For example, if you see an expression like (1 + 2) * 4, you know that you first evaluate the subexpression 1 + 2, getting a new expression 3 * 4. Then you evaluate 3 * 4. OCaml evaluation works the same way. As each point in time, the OCaml evaluator rewrites the program expression to another expression. Assuming that evaluation eventually terminates, eventually the whole expression is a value and then evaluation stops: the program is done. Or maybe the expression never reduces to a value, in which case you have an infinite loop.

Rewriting works by performing simple steps called reductions. In the arithmetic example above, the rewrite is performed by doing the reduction 1 + 23 within the larger expression, replacing the occurrence of the subexpression 1 + 2 with the right-hand side of the reduction, 3, therefore rewriting (1 + 2) * 4 to 3 * 4.

The next question is which reduction OCaml does. Fortunately, there is a simple rule. Evaluation works by always performing the rightmost reduction that is allowed. So we can describe evaluation precisely by simply describing all the allowed reductions.

OCaml has a bunch of built-in reduction rules that go well beyond simple arithmetic. For example, consider the if expression. It has two important reduction rules:

if true then e1 else e2e1
if false then e1 else e2e2

If the evaluator runs into an if expression, the first thing it does is try to reduce the conditional expression to either true or false. Then it can apply one of the two rules here.

For example, consider the term

if 2 = 3 then "hello" else "good" ^ "bye"

This term evaluates as follows:

if 2 = 3 then "hello" else "good" ^ "bye"
→ if false then "hello" else "good" ^ "bye"
→ "good" ^ "bye"
→ "goodbye"

Notice that the term "good" ^ "bye" isn't evaluated to produce the string value "goodbye" until the if term is removed. This is because if is lazy about evaluating its then and else clauses.

Evaluating the let term

The rewrite rule for the let expression introduces a new issue: how to deal with the bound variable. In the substitution model, the bound variable is replaced with the value that it is bound to. Evaluation of the let works by first evaluating all of the bindings. Then those bindings are substituted into the body of the let expression (the expression after the in). For example, here is an evaluation using let:

let x = 1 + 4 in x * 3
→  let x = 5 in x * 3
→  5 * 3
→  15

Notice that the variable x is only substituted once there is a value (5) to substitute. That is, OCaml eagerly evaluates the binding for the variable. Most languages (e.g., Java) work this way. However, in a lazy language like Haskell, the term 1 + 4 would be substituted for x instead. This could make a difference if evaluating the term could create an exception, side effect, or an infinite loop.

Therefore, we can write the rule for rewriting let roughly as follows:

let x = v in e
     e (with unbound occurrences of x replaced by v)

Remember that we use e to stand for an arbitrary expression (term), x to stand for an arbitrary identifier. We use v to stand for a value—that is, a fully evaluated term. By writing v in the rule, we indicate that the rewriting rule for let cannot be used until the term bound to x is fully evaluated. Values can be constants, applications of datatype constructors or tuples to other values, or anonymous function expressions. In fact, we can write a grammar for values:

v ::= c  |  X(v)   |   (v1,...,vn)  |   fun p -> e

Substitution

We wrote "with unbound occurrences of x replaced by v" above. The adjective "unbound" conveys an important but subtle issue. The term e may contain occurrences of x whose binding occurrence is not this binding x = v. It doesn't make sense to substitute v for these occurrences. For example, consider evaluation of the expression:

let x : int = 1 in
let f x = x in
let y = x + 1 in
  fun (a : string) -> x * 2

The next step of evaluation replaces only the magenta occurrences of x with 1, because these occurrences have the first declaration as their binding occurrence. Notice that the two occurrences of x inside the function f, which are respectively a binding and a bound occurrence, are not replaced. Thus, the result of this rewriting step is:

let f x = x in
let y = 1 + 1 in
  fun (a : string) -> 1 * 2

Let's write e{v/x} to mean the expression e with all unbound occurrences of x replaced by the value v. This operation is called substitution. Then we can restate the rule for evaluating let more simply:

let x = v in e        e{v/x}

This works because any occurrence of x in e is bound by exactly this declaration x = v.

Here are some examples of substitutions:

x{2/x}  =  2
x{2/y}  =  x
(fun y -> x) {"hi"/x} =  (fun y -> "hi")
(fun x -> x) {"hi"/x} =  (fun x -> x)
(f x) { fun y -> y / f }  =  ((fun y -> y) x)

One of the features that makes OCaml unusual is the ability to write complex patterns containing binding occurrences of variables. Pattern matching in OCaml causes these variables to be bound in such a way that the pattern matches the supplied value. This is can be a very concise and convenient way of binding variables. We can generalize the notation for substitution by writing e{v/p} to denote the expression e with all unbound occurrences of variables appearing in the pattern p replaced by the values obtained when p is matched against v. Examples:

y{(1, 2)/(x, y)}  =  2
(hd + 1 :: f tl){[7; 6; 3]/hd :: tl}  =  7 + 1 :: f [6; 3]

If a let expression introduces multiple declarations, we must substitute for all the bound variables simultaneously, once their bindings have all been evaluated.

Evaluating functions

Function application is the most interesting case. When a function is applied, OCaml substitutes the values passed as arguments for the parameters in the body of the function. Suppose we define a function abs as follows:

let abs (r : float) : float =
  if r < 0. then -. r else r

We would like the evaluation of abs (2. +. 1.) to proceed roughly as follows:

abs (2. +. 1.)
→  abs 3.
→  if 3. < 0. then -3. else 3.
→  if false then -3. else 3.
→  3.

In fact, we know that declaring a function is really just syntactic sugar for binding a variable to an anonymous function. So when we evaluate the declaration of abs above, we are really binding the identifier abs to the value fun r -> if r < 0. then -. r else r.

Therefore, the evaluation of a function call proceeds as in the following example:

let abs r =
  if r < 0. then -. r else r
in
  abs (2. +. 1.)
→  (fun r -> if r < 0. then -. r else r) (2. +. 1.)
    (* replacing occurrences of abs in let body with anonymous function *)
→  (fun r -> if r < 0. then -. r else r) 3.
→  if 3. < 0. then -. 3. else 3.
    (* replacing occurrences of r in function body with argument 3. *)
→  if false then -. 3. else 3.
→  3.

We can use the substitution operator to give a more precise rule for what happens when a function is called:

(fun x -> e) v  →  e{v/x}

Interestingly, this is the same result that we got from the expression let x = v in e. So this tells us that we can think of let as syntactic sugar for function application.

Some caveats

This is only a model for how OCaml expressions are evaluated. The truth is that the OCaml interpreter does not actually perform the substitutions. But the substitution model is accurate for describing purely functional execution (that is, when there are no side effects or mutable objects). The actual operation of the OCaml interpreter and compiler is a bit more complex and not that important to understand for now. The goal here is to allow us as programmers to understand what the program is going to do. We can do that much more clearly in terms of substitution than by thinking about the machine code, or for that matter in terms of the transistors in the computer and the electrons inside them. This evaluation model is an abstraction that hides some of the details you don't really need to know about.

Some aspects of the model should not be taken too literally. For example, you might think that function calls take longer if an argument variable appears many times in the body of the function. It might seem that a call to a function f are faster if it is defined as fun f x = x * 2 rather than as fun f x = x + x because the latter requires two substitutions. Actually the time required to pass arguments to a function typically depends only on the number of arguments. In reality, both definitions would be equally fast.