The declare construct is used for embedding declarations within executable code. Global declarations and declarations that are computed by a program are established by the proclaim construct.
Macro declaim, which is guaranteed to be recognized appropriately by the compiler, is often more convenient than proclaim for establishing global declarations.
A declare form is known as a declaration. Declarations may occur only at the beginning of the bodies of certain special operators; that is, a declaration may occur only as a statement of such a special operator, and all statements preceding it (if any) must also be declare forms (or possibly documentation strings, in some cases). Declarations may occur in lambda-expressions and in the forms listed here.
It is an error to attempt to evaluate a declaration. Those special operators that permit declarations to appear perform explicit checks for their presence.
It is permissible for a macro call to expand into a declaration and be recognized as such, provided that the macro call appears where a declaration may legitimately appear. (However, a macro call may not appear in place of a decl-spec.)
A declaration is recognized only as such if it appears explicitly, as a list whose car is the symbol declare, in the body of a relevant special operator. (Note, however, that it is still possible for a macro to expand into a call to the proclaim function.)
Each decl-spec is a list whose car is a symbol specifying the kind of declaration to be made. Declarations may be divided into two classes: those that concern the bindings of variables, and those that do not. (The special declaration is the sole exception: it effectively falls into both classes, as explained below.) Those that concern variable bindings apply only to the bindings made by the form at the head of whose body they appear. For example, in
the type declaration applies only to the outer binding of x, and not to the binding made in the let.
Declarations that do not concern themselves with variable bindings are pervasive, affecting all code in the body of the special operator. As an example of a pervasive declaration,
advises that everywhere within the body of foo the function floor should not be open-coded but called as an out-of-line subroutine.
Some special operators contain pieces of code that, properly speaking, are not part of the body of the special operator. Examples of this are initialization forms that provide values for bound variables, and the result forms of iteration constructs. In all cases such additional code is within the scope of any pervasive declarations appearing before the body of the special operator. Non-pervasive declarations have no effect on such code, except (of course) in those situations where the code is defined to be within the scope of the variables affected by such non-pervasive declarations. For example:
The reference to *print-circle* in the first line of this example is special because of the declaration in the second line.
In this rather nonsensical example, the inline declaration applies to the second and third calls to foo, but not to the first one. The special declaration of x causes the let form to make a special binding for x and causes the reference to x in the body of the let to be a special reference. The reference to x in the second call to foo is also a special reference. The reference to x in the first call to foo is a local reference, not a special one. The special declaration of z causes the reference to z in the call to foo to be a special reference; it will not refer to the parameter to nonsense named z, because that parameter binding has not been declared to be special. (The special declaration of z does not appear in the body of the defun, but in an inner construct, and therefore does not affect the binding of the parameter.)
X3J13 voted in January 1989 to replace the rules concerning the scope of declarations occurring at the head of a special operator or lambda-expression:
Note that the distinction between pervasive and non-pervasive declarations is eliminated. An important change from the first edition is that “initialization” forms are specifically not included as part of the body under the first rule; on the other hand, in many cases initialization forms may fall within the scope of certain declarations under the second rule.
X3J13 also voted in January 1989 to change the interpretation of type declarations (see section 9.2).
These changes affect the interpretation of some of the examples from the first edition.
Under the interpretation approved by X3J13, the type declaration applies to both bindings of x. More accurately, the type declaration is considered to apply to variable references rather than bindings, and the type declaration refers to every reference in the body of foo to a variable named x, no matter to what binding it may refer.
This example of the use of notinline stands unchanged, but the following slight extension of it would change:
Under first edition rules, the notinline declaration would be considered to apply to the call to floor in the initialization form for y. Under the interpretation approved by X3J13, the notinline would not apply to that particular call to floor. Instead the user must write something like
or perhaps
Similarly, the special declaration in
is not considered to apply to the reference in the initialization form for y in few. As for the nonsense example,
under the interpretation approved by X3J13, the inline declaration is no longer considered to apply to the second call to foo, because it is in an initialization form, which is no longer considered in the scope of the declaration. Similarly, the reference to x in that second call to foo is no longer taken to be a special reference, but a local reference to the second parameter of nonsense.
locally executes the forms as an implicit progn and returns the value(s) of the last form.
This change was made to accommodate the new compilation model for top-level forms in a file (see section 24.1). When a locally operator appears at top level, the forms in its body are processed as top-level forms. This means that one may, for example, meaningfully use locally to wrap declarations around a defun or defmacro form:
Without assurance that this works one must write something cumbersome such as
The function proclaim takes a decl-spec as its argument and puts it into effect globally. (Such a global declaration is called a proclamation.) Because proclaim is a function, its argument is always evaluated. This allows a program to compute a declaration and then put it into effect by calling proclaim.
Any variable names mentioned are assumed to refer to the dynamic values of the variable. For example, the proclamation
once executed, specifies that the dynamic value of tolerance should always be a floating-point number. Similarly, any function-names mentioned are assumed to refer to the global function definition.
A proclamation constitutes a universal declaration, always in force unless locally shadowed. For example,
advises that floor should normally be open-coded in-line by the compiler (but in the situation
it will be compiled out-of-line anyway in the body of foo, because of the shadowing local declaration to that effect).
X3J13 voted in January 1989 to clarify that such shadowing does not occur in the case of type declarations. If there is a local type declaration for a special variable and there is also a global proclamation for that same variable, then the value of the variable within the scope of the local declaration must be a member of the intersection of the two declared types. This is consistent with the treatment of nested local type declarations on which X3J13 also voted in January 1989 .
As a special case (so to speak), proclaim treats a special decl-spec as applying to all bindings as well as to all references of the mentioned variables.
For example, after
in a function definition such as
the parameter x will be bound as a special (dynamic) variable rather than as a lexical (static) variable. This facility should be used with caution. The usual way to define a globally special variable is with defvar or defparameter.
This macro is syntactically like declare and semantically like proclaim. It is an executable form and may be used anywhere proclaim may be called. However, each decl-spec is not evaluated.
If a call to this macro appears at top level in a file being processed by the file compiler, the proclamations are also made at compile time. As with other defining macros, it is unspecified whether or not the compile-time side effects of a declaim persist after the file has been compiled (see section 24.1).