Common Lisp the Language, 2nd Edition
In describing various features of the Common Lisp language, the notions of scope and extent are frequently useful. These notions arise when some object or construct must be referred to from some distant part of a program. Scope refers to the spatial or textual region of the program within which references may occur. Extent refers to the interval of time during which references may occur.
As a simple example, consider this program:
(defun copy-cell (x) (cons (car x) (cdr x)))
The scope of the parameter named x is the body of the defun form. There is no way to refer to this parameter from any other place but within the body of the defun. Similarly, the extent of the parameter x (for any particular call to copy-cell) is the interval from the time the function is invoked to the time it is exited. (In the general case, the extent of a parameter may last beyond the time of function exit, but that cannot occur in this simple case.)
Within Common Lisp, a referenceable entity is established by the execution of some language construct, and the scope and extent of the entity are described relative to the construct and the time (during execution of the construct) at which the entity is established. For the purposes of this discussion, the term ``entity'' refers not only to Common Lisp data objects, such as symbols and conses, but also to variable bindings (both ordinary and special), catchers, and go targets. It is important to distinguish between an entity and a name for the entity. In a function definition such as
(defun foo (x y) (* x (+ y 1)))
there is a single name, x, used to refer to the first parameter of the procedure whenever it is invoked; however, a new binding is established on every invocation. A binding is a particular parameter instance. The value of a reference to the name x depends not only on the scope within which it occurs (the one in the body of foo in the example occurs in the scope of the function definition's parameters) but also on the particular binding or instance involved. (In this case, it depends on the invocation during which the reference is made). More complicated examples appear at the end of this chapter.
There are a few kinds of scope and extent that are particularly useful in describing Common Lisp:
Example: the names of parameters to a function normally are lexically scoped.
Example: the with-open-file construct opens a connection to a file and creates a stream object to represent the connection. The stream object has indefinite extent, but the connection to the open file has dynamic extent: when control exits the with-open-file construct, either normally or abnormally, the stream is automatically closed.
Example: the binding of a ``special'' variable has dynamic extent.
Example: most Common Lisp data objects have indefinite extent.
Example: the bindings of lexically scoped parameters of a function have indefinite extent. (By contrast, in Algol the bindings of lexically scoped parameters of a procedure have dynamic extent.) The function definition
(defun compose (f g)
#'(lambda (x)
(funcall f (funcall g x))))
when given two arguments, immediately returns a function as its value. The parameter bindings for f and g do not disappear because the returned function, when called, could still refer to those bindings. Therefore
(funcall (compose #'sqrt #'abs) -9.0)
produces the value 3.0. (An analogous procedure would not necessarily work correctly in typical Algol implementations or, for that matter, in most Lisp dialects.)
In addition to the above terms, it is convenient to define dynamic scope to mean indefinite scope and dynamic extent. Thus we speak of ``special'' variables as having dynamic scope, or being dynamically scoped, because they have indefinite scope and dynamic extent: a special variable can be referred to anywhere as long as its binding is currently in effect.
The term ``dynamic scope'' is a misnomer. Nevertheless
it is both traditional and useful.
The above definitions do not take into account the possibility of shadowing. Remote reference of entities is accomplished by using names of one kind or another. If two entities have the same name, then the second may shadow the first, in which case an occurrence of the name will refer to the second and cannot refer to the first.
In the case of lexical scope, if two constructs that establish entities with the same name are textually nested, then references within the inner construct refer to the entity established by the inner one; the inner one shadows the outer one. Outside the inner construct but inside the outer one, references refer to the entity established by the outer construct. For example:
(defun test (x z) (let ((z (* x 2))) (print z)) z)
The binding of the variable z by the let construct shadows the parameter binding for the function test. The reference to the variable z in the print form refers to the let binding. The reference to z at the end of the function refers to the parameter named z.
In the case of dynamic extent, if the time intervals of two entities overlap, then one interval will necessarily be nested within the other one. This is a property of the design of Common Lisp.
A reference by name to an entity with dynamic extent will always refer to the entity of that name that has been most recently established that has not yet been disestablished. For example:
(defun fun1 (x) (catch 'trap (+ 3 (fun2 x)))) (defun fun2 (y) (catch 'trap (* 5 (fun3 y)))) (defun fun3 (z) (throw 'trap z))
Consider the call (fun1 7). The result will be 10. At the time the throw is executed, there are two outstanding catchers with the name trap: one established within procedure fun1, and the other within procedure fun2. The latter is the more recent, and so the value 7 is returned from the catch form in fun2. Viewed from within fun3, the catch in fun2 shadows the one in fun1. Had fun2 been defined as
(defun fun2 (y) (catch 'snare (* 5 (fun3 y))))
then the two catchers would have different names, and therefore the one in fun1 would not be shadowed. The result would then have been 7.
As a rule, this book simply speaks of the scope or extent of an entity; the possibility of shadowing is left implicit.
The important scope and extent rules in Common Lisp follow:
The rules of lexical scoping imply that lambda-expressions appearing in the function construct will, in general, result in ``closures'' over those non-special variables visible to the lambda-expression. That is, the function represented by a lambda-expression may refer to any lexically apparent non-special variable and get the correct value, even if the construct that established the binding has been exited in the course of execution. The compose example shown earlier in this chapter provides one illustration of this. The rules also imply that special variable bindings are not ``closed over'' as they may be in certain other dialects of Lisp.
Constructs that use lexical scope effectively generate a new name for each established entity on each execution. Therefore dynamic shadowing cannot occur (though lexical shadowing may). This is of particular importance when dynamic extent is involved. For example:
(defun contorted-example (f g x)
(if (= x 0)
(funcall f)
(block here
(+ 5 (contorted-example g
#'(lambda ()
(return-from here 4))
(- x 1))))))
Consider the call (contorted-example nil nil 2). This produces the result 4. During the course of execution, there are three calls on contorted-example, interleaved with two establishments of blocks:
(contorted-example nil nil 2) (block here...) (contorted-example nil #'(lambda () (return-from here
...) (contorted-example #'(lambda () (return-from here
At the time the funcall is executed
there are two block exit points outstanding, each apparently
named here. In the trace above, these exit points are distinguished
for expository purposes by subscripts.
The return-from form executed as a result of the funcall
operation
refers to the outer outstanding exit point
(here), not the
inner one (here).
This is a consequence of the rules of lexical scoping: it
refers to that exit point textually visible at the point of
execution of the function
construct (here abbreviated by the #' syntax) that resulted
in creation of the function object actually invoked by the funcall.
If, in this example, one were to change the form (funcall f) to
(funcall g), then the value of the call (contorted-example nil nil 2)
would be 9. The value would change because the funcall would cause the
execution of (return-from here 4), thereby causing
a return from the inner exit point (here).
When that occurs, the value 4 is returned from the
middle invocation of contorted-example, 5 is added to that
to get 9, and that value is returned from the outer block
and the outermost call to contorted-example. The point
is that the choice of exit point returned from has nothing to do with its
being innermost or outermost; rather,
it depends on the lexical scoping information
that is effectively packaged up with a lambda-expression when the
function construct is executed.
This function contorted-example works only because the function named by f is invoked during the extent of the exit point. Block exit points are like non-special variable bindings in having lexical scope, but they differ in having dynamic extent rather than indefinite extent. Once the flow of execution has left the block construct, the exit point is disestablished. For example:
(defun illegal-example ()
(let ((y (block here #'(lambda (z) (return-from here z)))))
(if (numberp y) y (funcall y 5))))
One might expect the call (illegal-example) to produce 5 by the following incorrect reasoning: the let statement binds the variable y to the value of the block construct; this value is a function resulting from the lambda-expression. Because y is not a number, it is invoked on the value 5. The return-from should then return this value from the exit point named here, thereby exiting from the block again and giving y the value 5 which, being a number, is then returned as the value of the call to illegal-example.
The argument fails only because exit points are defined in Common Lisp to have dynamic extent. The argument is correct up to the execution of the return-from. The execution of the return-from is an error, however, not because it cannot refer to the exit point, but because it does correctly refer to an exit point and that exit point has been disestablished.