A Common Lisp system evaluates forms with respect to lexical, dynamic, and global environments. The following sections describe the components of the Common Lisp evaluation model.
Forms fall into three categories: symbols, conses, and self-evaluating objects. The following sections explain these categories.
If a form is a symbol, then it is either a symbol macro or a variable.
The symbol names a symbol macro
if there is a binding of the symbol as a symbol macro
in the current lexical environment
(see define-symbol-macro and symbol-macrolet).
If the symbol is a symbol macro,
its expansion function is obtained.
The expansion function is a function of two arguments, and is invoked
by calling the macroexpand hook with
the expansion function as its first argument,
the symbol as its second argument,
and an environment object (corresponding to the current lexical environment)
as its third argument.
The macroexpand hook, in turn, calls the expansion function with the
form as its first argument and the environment as its second argument.
The value of the expansion function, which is passed through
by the macroexpand hook, is a form.
This resulting form is processed in place of the original symbol.
If a form is a symbol that is not a symbol macro, then it is the name of a variable, and the value of that variable is returned. There are three kinds of variables: lexical variables, dynamic variables, and constant variables. A variable can store one object. The main operations on a variable are to read1 and to write1
its value.
An error of type unbound-variable should be signaled if
an unbound variable is referenced.
Non-constant variables can be assigned by using setq
or bound3 by using let.
The next figure lists some defined names that
are applicable to assigning, binding, and defining variables.
|
Figure 3.1: Some Defined Names Applicable to Variables
The following is a description of each kind of variable.
A lexical variable is a variable that can be referenced only within the lexical scope of the form that establishes that variable; lexical variables have lexical scope. Each time a form creates a lexical binding of a variable, a fresh binding is established.
Within the scope of a binding for a lexical variable name, uses of that name as a variable are considered to be references to that binding except where the variable is shadowed2
by a form that establishes a fresh binding for that
variable name,
or by a form that locally declares the name special.
A lexical variable always has a value. There is no operator that introduces a binding for a lexical variable without giving it an initial value, nor is there any operator that can make a lexical variable be unbound.
Bindings of lexical variables are found in the lexical environment.
A variable is a dynamic variable if one of the following conditions hold:
special.
A dynamic variable can be referenced at any time in any program; there is no textual limitation on references to dynamic variables. At any given time, all dynamic variables with a given name refer to exactly one binding, either in the dynamic environment or in the global environment.
The value part of the binding for a dynamic variable might
be empty; in this case, the dynamic variable is said to have no value,
or to be unbound. A dynamic variable can be made unbound
by using makunbound.
The effect of binding a dynamic variable is to create a new binding to which all references to that dynamic variable in any program refer for the duration of the evaluation of the form that creates the dynamic binding.
A dynamic variable can be referenced outside the dynamic extent of a form that binds it. Such a variable is sometimes called a “global variable” but is still in all respects just a dynamic variable whose binding happens to exist in the global environment rather than in some dynamic environment.
A dynamic variable is unbound unless and until explicitly assigned a value, except for those variables whose initial value is defined in this specification or by an implementation.
Certain variables, called constant variables, are reserved as “named constants.”
The consequences are undefined if an attempt is made to
assign a value to,
or create
a binding for a constant variable,
except that a `compatible' redefinition of a constant variable
using defconstant is permitted; see the macro defconstant.
Keywords,
symbols defined by Common Lisp or the implementation
as constant (such as nil, t, and pi),
and symbols declared as constant using defconstant
are constant variables.
The same symbol can name both a lexical variable and a dynamic variable, but never in the same lexical environment.
In the following example, the symbol x is used,
at different times,
as the name of a lexical variable
and as the name of a dynamic variable.
(let ((x 1)) ;Binds a special variable X
(declare (special x))
(let ((x 2)) ;Binds a lexical variable X
(+ x ;Reads a lexical variable X
(locally (declare (special x))
x)))) ;Reads a special variable X
→ 3
A cons that is used as a form is called a compound form.
If the car of that compound form is a symbol, that symbol is the name of an operator, and the form is either a special form, a macro form, or a function form, depending on the function binding of the operator in the current lexical environment. If the operator is neither a special operator nor a macro name, it is assumed to be a function name (even if there is no definition for such a function).
If the car of the compound form is not a symbol, then that car must be a lambda expression, in which case the compound form is a lambda form.
How a compound form is processed depends on whether it is classified as a special form, a macro form, a function form, or a lambda form.
A special form is a form with special syntax, special evaluation rules, or both, possibly manipulating the evaluation environment, control flow, or both. A special operator has access to the current lexical environment and the current dynamic environment. Each special operator defines the manner in which its subexpressions are treated—which are forms, which are special syntax, etc.
Some special operators create new
lexical or dynamic environments for use during the
evaluation of subforms
of the special form. For example, block creates a
new lexical environment that is the same as the one in force
at the point of evaluation of the block form
with the addition of a binding of the block name
to an exit point from the block.
The set of special operator names is fixed in Common Lisp; no way is provided for the user to define a special operator. The next figure lists all of the Common Lisp symbols that have definitions as special operators.
|
Figure 3.2: Common Lisp Special Operators
If the operator names a macro, its associated macro function is applied to the entire form and the result of that application is used in place of the original form.
Specifically, a symbol names a macro in a given lexical environment if
macro-function is true of the
symbol and that environment.
The function returned by macro-function
is a function of two arguments, called the
expansion function.
The expansion function is invoked by calling the macroexpand hook with
the expansion function as its first argument,
the entire macro form as its second argument,
and an environment object (corresponding to the current lexical environment)
as its third argument.
The macroexpand hook, in turn, calls the expansion function with the
form as its first argument and the environment as its second argument.
The value of the expansion function, which is passed through
by the macroexpand hook, is a form.
The returned form is evaluated in place of the original form.
The consequences are undefined if a macro function destructively modifies any part of its form argument.
A macro name is not a function designator,
and cannot be used as the function argument to functions
such as apply, funcall, or map.
An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided.
The next figure lists some defined names that are applicable to macros.
|
Figure 3.3: Defined names applicable to macros
If the operator is a symbol naming a function, the form represents a function form, and the cdr of the list contains the forms which when evaluated will supply the arguments passed to the function.
When a function name is not defined,
an error of type undefined-function should be signaled at run time;
see Section 3.2.2.3 (Semantic Constraints).
A function form is evaluated as follows:
The subforms in the cdr of the original form are evaluated in left-to-right order in the current lexical and dynamic environments. The primary value of each such evaluation becomes an argument to the named function; any additional values returned by the subforms are discarded.
The functional value of the operator is retrieved from the lexical environment, and that function is invoked with the indicated arguments.
Although the order of evaluation of the argument subforms themselves is strictly left-to-right, it is not specified whether the definition of the operator in a function form is looked up before the evaluation of the argument subforms, after the evaluation of the argument subforms, or between the evaluation of any two argument subforms if there is more than one such argument subform. For example, the following might return 23 or 24.
(defun foo (x) (+ x 3)) (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4)))) (foo (progn (bar) 20))
A binding for a function name can be established in
one of several ways. A binding for a function name in
the global environment can be established by
defun,
setf of fdefinition,
setf of symbol-function,
ensure-generic-function,
defmethod (implicitly, due to ensure-generic-function),
or
defgeneric.
A binding for a function name in the lexical environment
can be established by
flet
or labels.
The next figure lists some defined names that are applicable to functions.
|
Figure 3.4: Some function-related defined names
A lambda form is similar to a function form, except that the function name is replaced by a lambda expression.
A lambda form is equivalent to using funcall of a
lexical closure of the lambda expression on the given arguments.
(In practice, some compilers are more likely to produce inline code
for a lambda form than for an arbitrary named function
that has been declared inline; however, such a difference
is not semantic.)
For further information, see Section 3.1.3 (Lambda Expressions).
A form that is neither a symbol nor a cons is defined to be a self-evaluating object. Evaluating such an object yields the same object as a result.
Certain specific symbols and conses might also happen to be “self-evaluating” but only as a special case of a more general set of rules for the evaluation of symbols and conses; such objects are not considered to be self-evaluating objects.
The consequences are undefined if literal objects (including self-evaluating objects) are destructively modified.
Numbers, pathnames, and arrays are examples of self-evaluating objects.
3 → 3 #c(2/3 5/8) → #C(2/3 5/8) #p"S:[BILL]OTHELLO.TXT" → #P"S:[BILL]OTHELLO.TXT" #(a b c) → #(A B C) "fred smith" → "fred smith"