source : CLtL2
Common Lisp the Language, 2nd Edition
Scope and Extent
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:
- Lexical scope. Here references to the established entity can occur only within certain program portions that are lexically (that is, textually) contained within the establishing construct. Typically the construct will have a part designated the body, and the scope of all entities established will be (or include) the body.
Example: the names of parameters to a function normally are lexically scoped.
- Indefinite scope. References may occur anywhere, in any program.
- Dynamic extent. References may occur at any time in the interval between establishment of the entity and the explicit disestablishment of the entity. As a rule, the entity is disestablished when execution of the establishing construct completes or is otherwise terminated. Therefore entities with dynamic extent obey a stack-like discipline, paralleling the nested executions of their establishing constructs.
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.
- Indefinite extent. The entity continues to exist as long as the possibility of reference remains. (An implementation is free to destroy the entity if it can prove that reference to it is no longer possible. Garbage collection strategies implicitly employ such proofs.)
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.
Implementation note: Behind the assertion that dynamic extents nest properly is the assumption that there is only a single program or process. Common Lisp does not address the problems of multiprogramming (timesharing) or multiprocessing (more than one active processor) within a single Lisp environment. The documentation for implementations that extend Common Lisp for multiprogramming or multiprocessing should be very clear on what modifications are induced by such extensions to the rules of extent and scope. Implementors should note that Common Lisp has been carefully designed to allow special variables to be implemented using either the ``deep binding'' technique or the ``shallow binding'' technique, but the two techniques have different semantic and performance implications for multiprogramming and multiprocessing.
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:
- Variable bindings normally have lexical scope and indefinite extent.
- Variable bindings for which there is a dynamic-extent declaration also have lexical scope and indefinite extent, but objects that are the values of such bindings may have dynamic extent. (The declaration is the programmer's guarantee that the program will behave correctly even if certain of the data objects have only dynamic extent rather than the usual indefinite extent.)
- Bindings of variable names to symbol macros by symbol-macrolet have lexical scope and indefinite extent.
- Variable bindings that are declared to be special have dynamic scope (indefinite scope and dynamic extent).
- Bindings of function names established, for example, by flet and labels have lexical scope and indefinite extent.
- Bindings of function names for which there is a dynamic-extent declaration also have lexical scope and indefinite extent, but function objects that are the values of such bindings may have dynamic extent.
- Bindings of function names to macros as established by macrolet have lexical scope and indefinite extent.
- Condition handlers and restarts have dynamic scope (see chapter 29).
- A catcher established by a catch or unwind-protect special form has dynamic scope.
- An exit point established by a block construct has lexical scope and dynamic extent. (Such exit points are also established by do, prog, and other iteration constructs.)
- The go targets established by a tagbody, named by the tags in the tagbody, and referred to by go have lexical scope and dynamic extent. (Such go targets may also appear as tags in the bodies of do, prog, and other iteration constructs.)
- Named constants such as nil and pi have indefinite scope and indefinite extent.
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.
