41. Closures in Drip

A counter, in Drip

In chapter 6 you wrote makeCounter in JavaScript. Here it is in Drip:

fn makeCounter() {
  let n = 0;
  fn count() {
    n = n + 1;
    return n;
  }
  return count;
}

let a = makeCounter();
print a(); // 1
print a(); // 2

Drip functions are values, so makeCounter can hand count back. Then a() runs count’s body, which uses n. But n was a local of a call that has already returned. Where does the interpreter find it?

Everything hangs on one decision. When a call starts, it gets a fresh environment for its parameters. Every environment has a parent. Which environment should be the parent of a call’s environment?

Three possible parents

There are three candidates:

1. The globals. Simple, but then count can’t see n at all. Looking up n searches the call’s environment, then the globals, and fails with Undefined variable 'n'.
2. The caller’s environment. Then what a name means depends on who calls the function. Chapter 6’s show/run example would print inner. That rule has a name, dynamic scope, and Drip doesn’t use it.
3. The environment the function was declared in. That is lexical scope, the rule JavaScript follows^[2], and the rule Drip follows too.

Option 3 has a cost: the function must remember where it was declared. That’s the closure field chapter 39 gave DripFunction and promised to explain.

The closure field

You’ve seen both halves of it in chapter 39. Look at them again with closures in mind. When the interpreter runs a fn declaration, it stores the current environment in the new function value:

case 'function':
  this.env.define(s.name.lexeme,
    new DripFunction(s, this.env));
  return;

And when the function is called, the new environment hangs off that stored one, not off whatever environment the caller is in:

class DripFunction {
  constructor(
    readonly decl: FunctionDecl,
    readonly closure: Environment,
  ) {}
  call(interp, args: Value[]): Value {
    const env = new Environment(
      this.closure,
    );
    this.decl.params.forEach((p, i) =>
      env.define(p.lexeme, args[i]),
    );
    return interp.executeFunctionBody(
      this.decl, env,
    );
  }
}

That’s the whole feature: one field, filled in at declaration, and used as the parent at every call. Inside makeCounter, the current environment is the call’s own, so that is what count keeps. Step through it:

fn makeCounter() {
  let n = 0;
  fn count() {
    n = n + 1;
    return n;
  }
  return count;
}
let a = makeCounter();
print a();
print a();

Environments that outlive their call

Look again at step 5. makeCounter has returned. So have the interpreter’s own TypeScript calls that ran its body, like executeFunctionBody, and their frames on the host stack (chapter 40) are gone. Yet the environment with n in it is still there.

That’s because an Environment is not in that stack frame. It is an ordinary object, made with new, so it lives on the heap (chapter 17). The frame only held a reference to it. A heap object stays alive as long as something still refers to it, and count.closure does. When nothing refers to it any more (say a is reassigned), the host language’s garbage collector is free to reclaim it.

Two functions made in the same call share one captured environment, and so they share its variables, live:

let get;
let set;
fn makeBox(v) {
  fn g() { return v; }
  fn s(x) { v = x; }
  get = g;
  set = s;
}

makeBox("old");
print get();
set("new");
print get();

Closures in a for loop

In chapter 6, each pass of a JavaScript for (let i ...) loop got its own i. Drip is different, and you can see why from chapter 38: a Drip for is desugared into a block that declares i once, wrapped around a while loop.

let f1;
let f2;
for (let i = 1; i <= 2; i = i + 1) {
  fn show() { print i; }
  if (i == 1) f1 = show;
  else f2 = show;
}
f1(); // 3
f2(); // 3

The loop body is a block, so each pass gets a new body environment. But i isn’t in it. It lives one level out, in the environment of the desugared block, and there is only one of those. To give each function its own value, make a call per pass, because every call makes a new environment:

fn capture(v) {
  fn show() { print v; }
  return show;
}

Your turn

let f1;
let f2;
let f3;
for (let i = 1; i <= 3; i = i + 1) {
  fn show() { print i; }
  if (i == 1) f1 = show;
  if (i == 2) f2 = show;
  if (i == 3) f3 = show;
}
f1();
f2();
f3();

class Env {
  constructor(parent) {
    this.vars = new Map();
    this.parent = parent;
  }
  get(name) {
    if (this.vars.has(name)) {
      return this.vars.get(name);
    }
    if (this.parent) {
      return this.parent.get(name);
    }
    throw new Error('no ' + name);
  }
}

function callFn(f, args) {
  // your code here
}

What you learned

• A Drip function value stores its captured environment: the one current when its declaration ran.
• Each call makes a new environment whose parent is that captured environment, not the globals and not the caller’s. That is lexical scope.
• Environments are heap objects, so their lifetime is “as long as something refers to them”. A closure can keep one alive long after its call has returned.
• Closures made in one call share variables, live.
• A Drip for declares its variable once, so closures made in the loop share it. A call per pass gives each its own.

Next: a bug hiding in this design, and a whole extra pass over the tree that fixes it.