The standard unit of interaction with a Common Lisp implementation is the form, which is simply a data object meant to be evaluated as a program to produce one or more values (which are also data objects). One may request evaluation of any data object, but only certain ones are meaningful. For instance, symbols and lists are meaningful forms, while arrays normally are not. Examples of meaningful forms are 3, whose value is 3, and (+ 3 4), whose value is 7. We write 3 ⇒ 3 and (+ 3 4) ⇒ 7 to indicate these facts. ( ⇒ means “evaluates to.”)
Meaningful forms may be divided into three categories: self-evaluating forms,
such as numbers; symbols, which stand for variables; and lists. The lists in turn
may be divided into three categories: special operators, macro calls, and function
calls.
All
All numbers, characters, strings, and bit-vectors are self-evaluating forms. When such an object is evaluated, that object (or possibly a copy in the case of numbers or characters) is returned as the value of the form. The empty list (), which is also the false value nil, is also a self-evaluating form: the value of nil is nil. Keywords (symbols written with a leading colon) also evaluate to themselves: the value of :start is :start.
It is an error to destructively modify any object that appears as a constant in executable code, whether as a self-evaluating form or within a quote special operator.
Symbols are used as names of variables in Common Lisp programs. When a symbol is evaluated as a form, the value of the variable it names is produced. For example, after doing (setq items 3), which assigns the value 3 to the variable named items, then items ⇒ 3. Variables can be assigned to, as by setq, or bound, as by let. Any program construct that binds a variable effectively saves the old value of the variable and causes it to have a new value, and on exit from the construct the old value is reinstated.
There are actually two kinds of variables in Common Lisp, called lexical (or static) variables and special (or dynamic) variables. At any given time either or both kinds of variable with the same name may have a current value. Which of the two kinds of variable is referred to when a symbol is evaluated depends on the context of the evaluation. The general rule is that if the symbol occurs textually within a program construct that creates a binding for a variable of the same name, then the reference is to the variable specified by the binding; if no such program construct textually contains the reference, then it is taken to refer to the special variable of that name.
The distinction between the two kinds of variable is one of scope and extent. A lexically bound variable can be referred to only by forms occurring at any place textually within the program construct that binds the variable. A dynamically bound (special) variable can be referred to at any time from the time the binding is made until the time evaluation of the construct that binds the variable terminates. Therefore lexical binding of variables imposes a spatial limitation on occurrences of references (but no temporal limitation, for the binding continues to exist as long as the possibility of reference remains). Conversely, dynamic binding of variables imposes a temporal limitation on occurrences of references (but no spatial limitation). For more information on scope and extent, see chapter 3.
The value a special variable has when there are currently no bindings of that variable is called the global value of the (special) variable. A global value can be given to a variable only by assignment, because a value given by binding is by definition not global.
It is possible for a special variable to have no value at all, in which case it is said to be unbound. By default, every global variable is unbound unless and until explicitly assigned a value, except for those global variables defined in this book or by the implementation already to have values when the Lisp system is first started. It is also possible to establish a binding of a special variable and then cause that binding to be valueless by using the function makunbound. In this situation the variable is also said to be “unbound,” although this is a misnomer; precisely speaking, it is bound but valueless. It is an error to refer to a variable that is unbound.
Reading an unbound variable or an undefined function must be detected in the highest safety setting (see the safety quality of the optimize declaration specifier) but the effect is undefined in any other safety setting. That is, reading an unbound variable should signal an error and reading an undefined function should signal an error. (“Reading a function” includes both references to the function using the function special operator, such as f in (function f), and references to the function in a call, such as f in (f x y).)
For the case of inline functions (in implementations where they are supported), a permitted point of view is that performing the inlining constitutes the read of the function, so that an fboundp check need not be done at execution time. Put another way, the effect of the application of fmakunbound to a function name on potentially inlined references to that function is undefined.
When an unbound variable is detected an error of type unbound-variable is signaled, and the name slot of the unbound-variable condition is initialized to the name of the offending variable.
When an undefined function is detected an error of type undefined-function is signaled, and the name slot of the undefined-function condition is initialized to the name of the offending function.
The condition type unbound-slot, which inherits from cell-error, has an additional slot instance, which can be initialized using the :instance keyword to make-condition. The function unbound-slot-instance accesses this slot.
The type of error signaled by the default primary method for the CLOS slot-unbound generic function is unbound-slot. The instance slot of the unbound-slot condition is initialized to the offending instance and the name slot is initialized to the name of the offending variable.
Certain global variables are reserved as “named constants.” They have a global value and may not be bound or assigned to. For example, the symbols t and nil are reserved. One may not assign a value to t or nil, and one may not bind t or nil. The global value of t is always t, and the global value of nil is always nil. Constant symbols defined by defconstant also become reserved and may not be further assigned to or bound (although they may be redefined, if necessary, by using defconstant again). Keyword symbols, which are notated with a leading colon, are reserved and may never be assigned to or bound; a keyword always evaluates to itself.
If a list is to be evaluated as a form, the first step is to examine the first element of the list. If the first element is one of the symbols appearing in table 5.1, then the list is called a special operator. (This use of the word “special” is unrelated to its use in the phrase “special variable.”)
Special operators are generally environment and control constructs. Every special operator has its own idiosyncratic syntax. An example is the if special operator: (if p (+ x 4) 5) in Common Lisp means what “if p then x+4 else 5” means in Algol.
The evaluation of a special operator normally produces a value or values, but the evaluation may instead call for a non-local exit; see return-from, go, and throw.
The set of special operators is fixed in Common Lisp; no way is provided for the user to define more. The user can create new syntactic constructs, however, by defining macros.
The set of special operators in Common Lisp is purposely kept very small because any program-analyzing program must have special knowledge about every type of special operator. Such a program needs no special knowledge about macros because it is simple to expand the macro and operate on the resulting expansion. (This is not to say that many such programs, particularly compilers, will not have such special knowledge. A compiler may be able to produce much better code if it recognizes such constructs as typecase and multiple-value-bind and gives them customized treatment.)
An implementation is free to implement as a macro any construct described herein as a special operator. Conversely, an implementation is free to implement as a special operator any construct described herein as a macro if an equivalent macro definition is also provided. The practical consequence is that the predicates macro-function and special-operator-p may both be true of the same symbol. It is recommended that a program-analyzing program process a form that is a list whose car is a symbol as follows:
If a form is a list and the first element is not the name of a special form, it may be the name of a macro; if so, the form is said to be a macro call. A macro is essentially a function from forms to forms that will, given a call to that macro, compute a new form to be evaluated in place of the macro call. (This computation is sometimes referred to as macro expansion.) For example, the macro named return will take a form such as (return x) and from that form compute a new form (return-from nil x). We say that the old form expands into the new form. The new form is then evaluated in place of the original form; the value of the new form is returned as the value of the original form.
Macro calls, and subforms of macro calls, need not be proper lists, but that use of dotted forms requires the macro definition to use “. var” or “&rest var” in order to match them properly. It is then the responsibility of the macro definition to recognize and appropriately handle such dotted forms or subforms.
There are a number of standard macros in Common Lisp, and the user can define more by using defmacro.
Macros provided by a Common Lisp implementation as described herein may expand into code that is not portable among differing implementations. That is, a macro call may be implementation-independent because the macro is defined in this book, but the expansion need not be. _________________________________
Implementation note: Implementors are encouraged to implement the macros defined in this book, as far as is possible, in such a way that the expansion will not contain any implementation-dependent special operators, nor contain as forms data objects that are not considered to be forms in Common Lisp. The purpose of this restriction is to ensure that the expansion can be processed by a program-analyzing program in an implementation-independent manner. There is no problem with a macro expansion containing calls to implementation-dependent functions. This restriction is not a requirement of Common Lisp; it is recognized that certain complex macros may be able to expand into significantly more efficient code in certain implementations by using implementation-dependent special operators in the macro expansion.
If a list is to be evaluated as a form and the first element is not a symbol that names a special operator or macro, then the list is assumed to be a function call. The first element of the list is taken to name a function. Any and all remaining elements of the list are forms to be evaluated; one value is obtained from each form, and these values become the arguments to the function. The function is then applied to the arguments. The functional computation normally produces a value, but it may instead call for a non-local exit; see throw. A function that does return may produce no value or several values; see values. If and when the function returns, whatever values it returns become the values of the function-call form.
For example, consider the evaluation of the form (+ 3 (* 4 5)). The symbol + names the addition function, not a special operator or macro. Therefore the two forms 3 and (* 4 5) are evaluated to produce arguments. The form 3 evaluates to 3, and the form (* 4 5) is a function call (to the multiplication function). Therefore the forms 4 and 5 are evaluated, producing arguments 4 and 5 for the multiplication. The multiplication function calculates the number 20 and returns it. The values 3 and 20 are then given as arguments to the addition function, which calculates and returns the number 23. Therefore we say (+ 3 (* 4 5)) ⇒ 23.
While the arguments in a function call are always evaluated in strict left-to-right order, whether the function to be called is determined before or after argument evaluation is unspecified. Programs are in error that rely on a particular order of evaluation of the first element of a function call relative to the argument forms.