Because some Lisp data objects are used to represent programs, one cannot always notate a constant data object in a program simply by writing the notation for the object unadorned; it would be ambiguous whether a constant object or a program fragment was intended. The quote special operator resolves this ambiguity.
There are two kinds of variables in Common Lisp, in effect: ordinary variables and function names. There are some similarities between the two kinds, and in a few cases there are similar functions for dealing with them, for example boundp and fboundp. However, for the most part the two kinds of variables are used for very different purposes: one to name defined functions, macros, and special operators, and the other to name data objects.
X3J13 voted in March 1989 to introduce the concept of a function-name, which may be either a symbol or a two-element list whose first element is the symbol setf and whose second element is a symbol. The primary purpose of this is to allow setf expander functions to be CLOS generic functions with user-defined methods. Many places in Common Lisp that used to require a symbol for a function name are changed to allow 2-lists as well; for example, defun is changed so that one may write (defun (setf foo) ...), and the function special operator is changed to accept any function-name. See also fdefinition.
By convention, any function named (setf f ) should return its first argument as its only value, in order to preserve the specification that setf returns its newvalue. See setf.
Implementations are free to extend the syntax of function-names to include lists beginning with additional symbols other than setf or lambda.
The value of an ordinary variable may be obtained simply by writing the name of the variable as a form to be executed. Whether this is treated as the name of a special variable or a lexical variable is determined by the presence or absence of an applicable special declaration; see chapter 9.
The following functions and special operators allow reference to the values of constants and variables in other ways.
(quote x) simply returns x. The object is not evaluated and may be any Lisp object whatsoever. This construct allows any Lisp object to be written as a constant value in a program. For example:
Since quote forms are so frequently useful but somewhat cumbersome to type, a standard abbreviation is defined for them: any form f preceded by a single quote ( ’ ) character is assumed to have (quote ) wrapped around it to make (quote f ). For example:
is normally interpreted by read to mean
See section 22.1.3.
It is an error to destructively modify any object that appears as a constant in executable code, whether within a quote special operator or as a self-evaluating form.
See section 24.1 for a discussion of how quoted constants are treated by the compiler.
X3J13 voted in March 1989 to clarify that eval and compile are not permitted either to copy or to coalesce (“collapse”) constants (see eq) appearing in the code they process; the resulting program behavior must refer to objects that are eql to the corresponding objects in the source code. Moreover, the constraints introduced by the votes on issues and on what kinds of objects may appear as constants apply only to compile-file (see section 24.1).
The value of function is always the functional interpretation of fn; fn is interpreted as if it had appeared in the functional position of a function invocation. In particular, if fn is a symbol, the functional definition associated with that symbol is returned; see symbol-function. If fn is a lambda-expression, then a “lexical closure” is returned, that is, a function that when invoked will execute the body of the lambda-expression in such a way as to observe the rules of lexical scoping properly.
X3J13 voted in June 1988 to specify that the result of a function special operator is always of type function. This implies that a form (function fn) may be interpreted as (the (function fn)).
It is an error to use the function special operator on a symbol that does not denote a function in the lexical or global environment in which the special operator appears. Specifically, it is an error to use the function special operator on a symbol that denotes a macro or special operator. Some implementations may choose not to signal this error for performance reasons, but implementations are forbidden to extend the semantics of function in this respect; that is, an implementation is not allowed to define the failure to signal an error to be a “useful” behavior.
function accepts any function-name (a symbol or a list whose car is setf—see section 7.1) as well as lambda-expressions. Thus one may write (function (setf cadr)) to refer to the setf expansion function for cadr.
For example:
The result of (adder 3) is a function that will add 3 to its argument:
This works because function creates a closure of the inner lambda-expression that is able to refer to the value 3 of the variable x even after control has returned from the function adder.
More generally, a lexical closure in effect retains the ability to refer to lexically visible bindings, not just values. Consider this code:
The function two-funs returns a list of two functions, each of which refers to the binding of the variable x created on entry to the function two-funs when it was called with argument 6. This binding has the value 6 initially, but setq can alter a binding. The lexical closure created for the first lambda-expression does not “snapshot” the value 6 for x when the closure is created. The second function can be used to alter the binding (to 43, in the example), and this altered value then becomes accessible to the first function.
In situations where a closure of a lambda-expression over the same set of bindings may be produced more than once, the various resulting closures may or may not be eq, at the discretion of the implementation. For example:
The result of the above expression is a list of ten closures. Each logically requires only the binding of x. It is the same binding in each case, so the ten closures may or may not be the same identical (eq) object. On the other hand, the result of the expression
is also a list of ten closures. However, in this case no two of the closures may be eq, because each closure is over a distinct binding of x, and these bindings can be behaviorally distinguished because of the use of setq.
The question of distinguishable behavior is important; the result of the simpler expression
is a list of ten closures that may be pairwise eq. Although one might think that a different binding of x is involved for each closure (which is indeed the case), the bindings cannot be distinguished because their values are identical and immutable, there being no occurrence of setq on x. A compiler would therefore be justified in transforming the expression to
where clearly the closures may be the same after all. The general rule, then, is that the implementation is free to have two distinct evaluations of the same function form produce identical (eq) closures if it can prove that the two conceptually distinct resulting closures must in fact be behaviorally identical with respect to invocation. This is merely a permitted optimization; a perfectly valid implementation might simply cause every distinct evaluation of a function form to produce a new closure object not eq to any other.
Frequently a compiler can deduce that a closure in fact does not need to close over any variable bindings. For example, in the code fragment
the function (lambda (x) (+ x 2)) contains no references to any outside entity. In this important special case, the same “closure” may be used as the value for all evaluations of the function special operator. Indeed, this value need not be a closure object at all; it may be a simple compiled function containing no environment information. This example is simply a special case of the foregoing discussion and is included as a hint to implementors familiar with previous methods of implementing Lisp. The distinction between closures and other kinds of functions is somewhat pointless, actually, as Common Lisp defines no particular representation for closures and no way to distinguish between closures and non-closure functions. All that matters is that the rules of lexical scoping be obeyed.
Since function forms are so frequently useful but somewhat cumbersome to type, a standard abbreviation is defined for them: any form f preceded by #’ (# followed by an apostrophe) is assumed to have (function ) wrapped around it to make (function f ). For example,
is normally interpreted by read to mean
See section 22.1.4.
symbol-value returns the current value of the dynamic (special) variable named by symbol. An error occurs if the symbol has no value; see boundp and makunbound. Note that constant symbols are really variables that cannot be changed, and so symbol-value may be used to get the value of a named constant. In particular, symbol-value of a keyword will return that keyword.
symbol-value cannot access the value of a lexical variable.
This function is particularly useful for implementing interpreters for languages embedded in Lisp. The corresponding assignment primitive is set; alternatively, symbol-value may be used with setf.
symbol-function returns the current global function definition named by symbol. An error is signalled if the symbol has no function definition; see fboundp. Note that the definition may be a function or may be an object representing a special operator or macro. In the latter case, however, it is an error to attempt to invoke the object as a function. If it is desired to process macros, special operators, and functions equally well, as when writing an interpreter, it is best first to test the symbol with macro-function and special-operator-p and then to invoke the functional value only if these two tests both yield false.
This function is particularly useful for implementing interpreters for languages embedded in Lisp.
symbol-function cannot access the value of a lexical function name produced by flet or labels; it can access only the global function value.
The global function definition of a symbol may be altered by using setf with symbol-function. Performing this operation causes the symbol to have only the specified definition as its global function definition; any previous definition, whether as a macro or as a function, is lost. It is an error to attempt to redefine the name of a special form (see table 5.1).
X3J13 voted in June 1988 to clarify the behavior of symbol-function in the light of the redefinition of the type function.
X3J13 voted in March 1989 to add the function fdefinition to the language. It is exactly like symbol-function except that its argument may be any function-name (a symbol or a list whose car is setf—see section 7.1); it returns the current global function definition named by the argument function-name. One may use fdefinition with setf to change the current global function definition associated with a function-name.
boundp is true if the dynamic (special) variable named by symbol has a value; otherwise, it returns nil.
See also set and makunbound.
fboundp is true if the symbol has a global function definition. Note that fboundp is true when the symbol names a special operator or macro. macro-function and special-operator-p may be used to test for these cases.
Despite the tightening of the definition of the type function, fboundp must return true when the argument names a special operator or macro.
See also symbol-function and fmakunbound.
fboundp accepts any function-name (a symbol or a list whose car is setf—see section 7.1). Thus one may write (fboundp ’(setf cadr)) to determine whether a setf expansion function has been globally defined for cadr.
The function special-operator-p takes a symbol. If the symbol globally names a special operator, then a non-nil value is returned; otherwise nil is returned. A returned non-nil value is typically a function of implementation-dependent nature that can be used to interpret (evaluate) the special operator.
It is possible for both special-operator-p and macro-function to be true of a symbol. This is possible because an implementation is permitted to implement any macro also as a special operator for speed. On the other hand, the macro definition must be available for use by programs that understand only the standard special operators listed in table 5.1.
The following facilities allow the value of a variable (more specifically, the value associated with the current binding of the variable) to be altered. Such alteration is different from establishing a new binding. Constructs for establishing new bindings of variables are described in section 7.5.
The special operator (setq var1 form1 var2 form2 ...) is the “simple variable assignment statement” of Lisp. First form1 is evaluated and the result is stored in the variable var1, then form2 is evaluated and the result stored in var2, and so forth. The variables are represented as symbols, of course, and are interpreted as referring to static or dynamic instances according to the usual rules. Therefore setq may be used for assignment of both lexical and special variables.
setq returns the last value assigned, that is, the result of the evaluation of its last argument. As a boundary case, the form (setq) is legal and returns nil. There must be an even number of argument forms. For example, in
x is set to 6, y is set to (6), and the setq returns (6). Note that the first assignment is performed before the second form is evaluated, allowing that form to use the new value of x.
See also the description of setf, the Common Lisp “general assignment statement” that is capable of assigning to variables, array elements, and other locations.
Some programmers choose to avoid setq as a matter of style, always using setf for any kind of structure modification. Others use setq with simple variable names and setf with all other generalized variables.
If any var refers not to an ordinary variable but to a binding made by symbol-macrolet, then that var is handled as if setf had been used instead of setq.
A psetq form is just like a setq form, except that the assignments happen in parallel. First all of the forms are evaluated, and then the variables are set to the resulting values. The value of the psetq form is nil. For example:
In this example, the values of a and b are exchanged by using parallel assignment. (If several variables are to be assigned in parallel in the context of a loop, the do construct may be appropriate.)
See also the description of psetf, the Common Lisp “general parallel assignment statement” that is capable of assigning to variables, array elements, and other locations.
If any var refers not to an ordinary variable but to a binding made by symbol-macrolet, then that var is handled as if psetf had been used instead of psetq.
set allows alteration of the value of a dynamic (special) variable. set causes the dynamic variable named by symbol to take on value as its value.
The value may be any Lisp datum whatsoever.
Only the value of the current dynamic binding is altered; if there are no bindings in effect, the most global value is altered. For example,
will either set c to foo or set d to foo, depending on the outcome of the test (eq a b).
set returns value as its result.
set cannot alter the value of a local (lexically bound) variable. The special operator setq is usually used for altering the values of variables (lexical or dynamic) in programs. set is particularly useful for implementing interpreters for languages embedded in Lisp. See also progv, a construct that performs binding rather than assignment of dynamic variables.
makunbound causes the dynamic (special) variable named by symbol to become unbound (have no value). fmakunbound does the analogous thing for the global function definition named by symbol. For example:
Both functions return symbol as the result value.
fmakunbound accepts any function-name (a symbol or a list whose car is setf—see section 7.1). Thus one may write (fmakunbound ’(setf cadr)) to remove any global definition of a setf expansion function for cadr.