Question

Recently I met a conflict between set! and closures when implementing a scheme interpreter.

The description of (set! var expr) is the following: (tspl)

set! does not establish a new binding for var but rather alters the value of an existing binding. It first evaluates expr, then assigns var to the value of expr. Any subsequent reference to var within the scope of the altered binding evaluates to the new value.

And the description about the binding of a lambda is: (tspl)

When the procedure is created, the bindings of all variables occurring free within the body, excluding the formal parameters, are retained with the procedure. Subsequently, whenever the procedure is applied to a sequence of actual parameters, the formal parameters are bound to the actual parameters, the retained bindings are restored, and the body is evaluated.

I don’t really understand what does it mean ‘free variable‘, My implementation of a closure is to create a snapshot of all the currently available variables and store the snapshot into a closure. Whenever the closure is executed, it does the following works in order: (code)

1. create a local scope(context) that refers the parent scope of currently executing environment.
2. store all variables in the snapshot into the new-created scope.
3. store all actual arguments with names of corresponding parameters in the new scope.
4. evaluate the body as a list in the new scope.

My method to implement a set! operator is: (code)

1. find the scope upwards(along the parent reference), till the one which contains a variable with the given name.
2. set the value of the variable in that scope to the new one.

This procedure seems work in most times, however when there’s a set! inside that aims to modify an external variable out of the local scope, that turns impossible since set! can’t really find the REAL variable but just the one stored in the snapshot of the closure.

Let me explain this in code:

(define x 3)

((lambda ()      ;; binding(snapshot) == { x: 3 }
   (set! x 4)    ;; changing the value in local scope which derived from the snapshot.
   (display x))) ;; ==> 4

(display x)      ;; ==> 3

How can I solve this conflict?

Answer 1

Easy! Don’t use snapshots. Access higher-level scopes directly.