Common Lisp is a huge language, and Common Lisp systems tend to be massive and extremely complex. Emacs Lisp, by contrast, is rather minimalist in the choice of Lisp features it offers the programmer. As Emacs Lisp programmers have grown in number, and the applications they write have grown more ambitious, it has become clear that Emacs Lisp could benefit from many of the conveniences of Common Lisp.
The CL package adds a number of Common Lisp functions and control structures to Emacs Lisp. While not a 100% complete implementation of Common Lisp, CL adds enough functionality to make Emacs Lisp programming significantly more convenient.
Some Common Lisp features have been omitted from this package for various reasons:
assoc function is incompatible with the
Common Lisp assoc. In such cases, this package usually
adds the suffix `*' to the function name of the Common
Lisp version of the function (e.g., assoc*).
The package described here was written by Dave Gillespie, `daveg@synaptics.com'. It is a total rewrite of the original 1986 `cl.el' package by Cesar Quiroz. Most features of the the Quiroz package have been retained; any incompatibilities are noted in the descriptions below. Care has been taken in this version to ensure that each function is defined efficiently, concisely, and with minimal impact on the rest of the Emacs environment.
Lisp code that uses features from the CL package should include at the beginning:
(require 'cl)
If you want to ensure that the new (Gillespie) version of CL
is the one that is present, add an additional (require 'cl-19)
call:
(require 'cl) (require 'cl-19)
The second call will fail (with "`cl-19.el' not found") if the old `cl.el' package was in use.
It is safe to arrange to load CL at all times, e.g.,
in your `.emacs' file. But it's a good idea, for portability,
to (require 'cl) in your code even if you do this.
The Common Lisp package is organized into four files:
cadr function won't need to pay
the overhead of loading the more advanced functions.
delete-if and assoc*.
The file `cl.el' includes all necessary autoload
commands for the functions and macros in the other three files.
All you have to do is (require 'cl), and `cl.el'
will take care of pulling in the other files when they are
needed.
There is another file, `cl-compat.el', which defines some
routines from the older `cl.el' package that are no longer
present in the new package. This includes internal routines
like setelt and zip-lists, deprecated features
like defkeyword, and an emulation of the old-style
multiple-values feature. See section Old CL Compatibility.
Installation of the CL package is simple: Just put the
byte-compiled files `cl.elc', `cl-extra.elc',
`cl-seq.elc', `cl-macs.elc', and `cl-compat.elc'
into a directory on your load-path.
There are no special requirements to compile this package: The files do not have to be loaded before they are compiled, nor do they need to be compiled in any particular order.
You may choose to put the files into your main `lisp/'
directory, replacing the original `cl.el' file there. Or,
you could put them into a directory that comes before `lisp/'
on your load-path so that the old `cl.el' is
effectively hidden.
Also, format the `cl.texinfo' file and put the resulting Info files in the `info/' directory or another suitable place.
You may instead wish to leave this package's components all in
their own directory, and then add this directory to your
load-path and (Emacs 19 only) Info-directory-list.
Add the directory to the front of the list so the old CL
package and its documentation are hidden.
Except where noted, all functions defined by this package have the same names and calling conventions as their Common Lisp counterparts.
Following is a complete list of functions whose names were changed from Common Lisp, usually to avoid conflicts with Emacs. In each case, a `*' has been appended to the Common Lisp name to obtain the Emacs name:
defun* defsubst* defmacro* function* member* assoc* rassoc* get* remove* delete* mapcar* sort* floor* ceiling* truncate* round* mod* rem* random*
Internal function and variable names in the package are prefixed
by cl-. Here is a complete list of functions not
prefixed by cl- which were not taken from Common Lisp:
member delete remove remq rassoc floatp-safe lexical-let lexical-let* callf callf2 letf letf* defsubst* defalias add-hook eval-when-compile
(Most of these are Emacs 19 features provided to Emacs 18 users,
or introduced, like remq, for reasons of symmetry
with similar features.)
The following simple functions and macros are defined in `cl.el'; they do not cause other components like `cl-extra' to be loaded.
eql floatp-safe abs endp evenp oddp plusp minusp last butlast nbutlast caar .. cddddr list* ldiff rest first .. tenth member [1] copy-list subst mapcar* [2] adjoin [3] acons pairlis when unless pop [4] push [4] pushnew [3,4] incf [4] decf [4] proclaim declaim add-hook
[1] This is the Emacs 19-compatible function, not member*.
[2] Only for one sequence argument or two list arguments.
[3] Only if :test is eq, equal, or unspecified,
and :key is not used.
[4] Only when place is a plain variable name.
@chapno=4
This section describes features of the CL package which have to
do with programs as a whole: advanced argument lists for functions,
and the eval-when construct.
@secno=1
Emacs Lisp's notation for argument lists of functions is a subset of
the Common Lisp notation. As well as the familiar &optional
and &rest markers, Common Lisp allows you to specify default
values for optional arguments, and it provides the additional markers
&key and &aux.
Since argument parsing is built-in to Emacs, there is no way for this package to implement Common Lisp argument lists seamlessly. Instead, this package defines alternates for several Lisp forms which you must use if you need Common Lisp argument lists.
Special Form: defun* name arglist body...
This form is identical to the regular defun form, except
that arglist is allowed to be a full Common Lisp argument
list. Also, the function body is enclosed in an implicit block
called name; see section Blocks and Exits.
Special Form: defsubst* name arglist body...
This is just like defun*, except that the function that
is defined is automatically proclaimed inline, i.e.,
calls to it may be expanded into in-line code by the byte compiler.
This is analogous to the defsubst form in Emacs 19;
defsubst* uses a different method (compiler macros) which
works in all version of Emacs, and also generates somewhat more
efficient inline expansions. In particular, defsubst*
arranges for the processing of keyword arguments, default values,
etc., to be done at compile-time whenever possible.
Special Form: defmacro* name arglist body...
This is identical to the regular defmacro form,
except that arglist is allowed to be a full Common Lisp
argument list. The &environment keyword is supported as
described in Steele. The &whole keyword is supported only
within destructured lists (see below); top-level &whole
cannot be implemented with the current Emacs Lisp interpreter.
The macro expander body is enclosed in an implicit block called
name.
Special Form: function* symbol-or-lambda
This is identical to the regular function form,
except that if the argument is a lambda form then that
form may use a full Common Lisp argument list.
Also, all forms (such as defsetf and flet) defined
in this package that include arglists in their syntax allow
full Common Lisp argument lists.
Note that it is not necessary to use defun* in
order to have access to most CL features in your function.
These features are always present; defun*'s only
difference from defun is its more flexible argument
lists and its implicit block.
The full form of a Common Lisp argument list is
(var... &optional (var initform svar)... &rest var &key ((keyword var) initform svar)... &aux (var initform)...)
Each of the five argument list sections is optional. The svar, initform, and keyword parts are optional; if they are omitted, then `(var)' may be written simply `var'.
The first section consists of zero or more required arguments. These arguments must always be specified in a call to the function; there is no difference between Emacs Lisp and Common Lisp as far as required arguments are concerned.
The second section consists of optional arguments. These
arguments may be specified in the function call; if they are not,
initform specifies the default value used for the argument.
(No initform means to use nil as the default.) The
initform is evaluated with the bindings for the preceding
arguments already established; (a &optional (b (1+ a)))
matches one or two arguments, with the second argument defaulting
to one plus the first argument. If the svar is specified,
it is an auxiliary variable which is bound to t if the optional
argument was specified, or to nil if the argument was omitted.
If you don't use an svar, then there will be no way for your
function to tell whether it was called with no argument, or with
the default value passed explicitly as an argument.
The third section consists of a single rest argument. If
more arguments were passed to the function than are accounted for
by the required and optional arguments, those extra arguments are
collected into a list and bound to the "rest" argument variable.
Common Lisp's &rest is equivalent to that of Emacs Lisp.
Common Lisp accepts &body as a synonym for &rest in
macro contexts; this package accepts it all the time.
The fourth section consists of keyword arguments. These are optional arguments which are specified by name rather than positionally in the argument list. For example,
(defun* foo (a &optional b &key c d (e 17)))
defines a function which may be called with one, two, or more
arguments. The first two arguments are bound to a and
b in the usual way. The remaining arguments must be
pairs of the form :c, :d, or :e followed
by the value to be bound to the corresponding argument variable.
(Symbols whose names begin with a colon are called keywords,
and they are self-quoting in the same way as nil and
t.)
For example, the call (foo 1 2 :d 3 :c 4) sets the five
arguments to 1, 2, 4, 3, and 17, respectively. If the same keyword
appears more than once in the function call, the first occurrence
takes precedence over the later ones. Note that it is not possible
to specify keyword arguments without specifying the optional
argument b as well, since (foo 1 :c 2) would bind
b to the keyword :c, then signal an error because
2 is not a valid keyword.
If a keyword symbol is explicitly specified in the argument list as shown in the above diagram, then that keyword will be used instead of just the variable name prefixed with a colon. You can specify a keyword symbol which does not begin with a colon at all, but such symbols will not be self-quoting; you will have to quote them explicitly with an apostrophe in the function call.
Ordinarily it is an error to pass an unrecognized keyword to
a function, e.g., (foo 1 2 :c 3 :goober 4). You can ask
Lisp to ignore unrecognized keywords, either by adding the
marker &allow-other-keys after the keyword section
of the argument list, or by specifying an :allow-other-keys
argument in the call whose value is non-nil. If the
function uses both &rest and &key at the same time,
the "rest" argument is bound to the keyword list as it appears
in the call. For example:
(defun* find-thing (thing &rest rest &key need &allow-other-keys)
(or (apply 'member* thing thing-list :allow-other-keys t rest)
(if need (error "Thing not found"))))
This function takes a :need keyword argument, but also
accepts other keyword arguments which are passed on to the
member* function. allow-other-keys is used to
keep both find-thing and member* from complaining
about each others' keywords in the arguments.
In Common Lisp, keywords are recognized by the Lisp parser itself
and treated as special entities. In Emacs, keywords are just
symbols whose names begin with colons, which defun* has
arranged to set equal to themselves so that they will essentially
be self-quoting.
As a (significant) performance optimization, this package
implements the scan for keyword arguments by calling memq
to search for keywords in a "rest" argument. Technically
speaking, this is incorrect, since memq looks at the
odd-numbered values as well as the even-numbered keywords.
The net effect is that if you happen to pass a keyword symbol
as the value of another keyword argument, where that
keyword symbol happens to equal the name of a valid keyword
argument of the same function, then the keyword parser will
become confused. This minor bug can only affect you if you
use keyword symbols as general-purpose data in your program;
this practice is strongly discouraged in Emacs Lisp.
The fifth section of the argument list consists of auxiliary
variables. These are not really arguments at all, but simply
variables which are bound to nil or to the specified
initforms during execution of the function. There is no
difference between the following two functions, except for a
matter of stylistic taste:
(defun* foo (a b &aux (c (+ a b)) d)
body)
(defun* foo (a b)
(let ((c (+ a b)) d)
body))
Argument lists support destructuring. In Common Lisp,
destructuring is only allowed with defmacro; this package
allows it with defun* and other argument lists as well.
In destructuring, any argument variable (var in the above
diagram) can be replaced by a list of variables, or more generally,
a recursive argument list. The corresponding argument value must
be a list whose elements match this recursive argument list.
For example:
(defmacro* dolist ((var listform &optional resultform)
&rest body)
...)
This says that the first argument of dolist must be a list
of two or three items; if there are other arguments as well as this
list, they are stored in body. All features allowed in
regular argument lists are allowed in these recursive argument lists.
In addition, the clause `&whole var' is allowed at the
front of a recursive argument list. It binds var to the
whole list being matched; thus (&whole all a b) matches
a list of two things, with a bound to the first thing,
b bound to the second thing, and all bound to the
list itself. (Common Lisp allows &whole in top-level
defmacro argument lists as well, but Emacs Lisp does not
support this usage.)
One last feature of destructuring is that the argument list may be
dotted, so that the argument list (a b . c) is functionally
equivalent to (a b &rest c).
If the optimization quality safety is set to 0
(see section Declarations), error checking for wrong number of
arguments and invalid keyword arguments is disabled. By default,
argument lists are rigorously checked.
Normally, the byte-compiler does not actually execute the forms in
a file it compiles. For example, if a file contains (setq foo t),
the act of compiling it will not actually set foo to t.
This is true even if the setq was a top-level form (i.e., not
enclosed in a defun or other form). Sometimes, though, you
would like to have certain top-level forms evaluated at compile-time.
For example, the compiler effectively evaluates defmacro forms
at compile-time so that later parts of the file can refer to the
macros that are defined.
Special Form: eval-when (situations...) forms...
This form controls when the body forms are evaluated.
The situations list may contain any set of the symbols
compile, load, and eval (or their long-winded
ANSI equivalents, :compile-toplevel, :load-toplevel,
and :execute).
The eval-when form is handled differently depending on
whether or not it is being compiled as a top-level form.
Specifically, it gets special treatment if it is being compiled
by a command such as byte-compile-file which compiles files
or buffers of code, and it appears either literally at the
top level of the file or inside a top-level progn.
For compiled top-level eval-whens, the body forms are
executed at compile-time if compile is in the situations
list, and the forms are written out to the file (to be executed
at load-time) if load is in the situations list.
For non-compiled-top-level forms, only the eval situation is
relevant. (This includes forms executed by the interpreter, forms
compiled with byte-compile rather than byte-compile-file,
and non-top-level forms.) The eval-when acts like a
progn if eval is specified, and like nil
(ignoring the body forms) if not.
The rules become more subtle when eval-whens are nested;
consult Steele (second edition) for the gruesome details (and
some gruesome examples).
Some simple examples:
;; Top-level forms in foo.el: (eval-when (compile) (setq foo1 'bar)) (eval-when (load) (setq foo2 'bar)) (eval-when (compile load) (setq foo3 'bar)) (eval-when (eval) (setq foo4 'bar)) (eval-when (eval compile) (setq foo5 'bar)) (eval-when (eval load) (setq foo6 'bar)) (eval-when (eval compile load) (setq foo7 'bar))
When `foo.el' is compiled, these variables will be set during the compilation itself:
foo1 foo3 foo5 foo7 ; `compile'
When `foo.elc' is loaded, these variables will be set:
foo2 foo3 foo6 foo7 ; `load'
And if `foo.el' is loaded uncompiled, these variables will be set:
foo4 foo5 foo6 foo7 ; `eval'
If these seven eval-whens had been, say, inside a defun,
then the first three would have been equivalent to nil and the
last four would have been equivalent to the corresponding setqs.
Note that (eval-when (load eval) ...) is equivalent
to (progn ...) in all contexts. The compiler treats
certain top-level forms, like defmacro (sort-of) and
require, as if they were wrapped in (eval-when
(compile load eval) ...).
Emacs 19 includes two special forms related to eval-when.
One of these, eval-when-compile, is not quite equivalent to
any eval-when construct and is described below. This package
defines a version of eval-when-compile for the benefit of
Emacs 18 users.
The other form, (eval-and-compile ...), is exactly
equivalent to `(eval-when (compile load eval) ...)' and
so is not itself defined by this package.
Special Form: eval-when-compile forms...
The forms are evaluated at compile-time; at execution time,
this form acts like a quoted constant of the resulting value. Used
at top-level, eval-when-compile is just like `eval-when
(compile eval)'. In other contexts, eval-when-compile
allows code to be evaluated once at compile-time for efficiency
or other reasons.
This form is similar to the `#.' syntax of true Common Lisp.
Special Form: load-time-value form
The form is evaluated at load-time; at execution time, this form acts like a quoted constant of the resulting value.
Early Common Lisp had a `#,' syntax that was similar to
this, but ANSI Common Lisp replaced it with load-time-value
and gave it more well-defined semantics.
In a compiled file, load-time-value arranges for form
to be evaluated when the `.elc' file is loaded and then used
as if it were a quoted constant. In code compiled by
byte-compile rather than byte-compile-file, the
effect is identical to eval-when-compile. In uncompiled
code, both eval-when-compile and load-time-value
act exactly like progn.
(defun report ()
(insert "This function was executed on: "
(current-time-string)
", compiled on: "
(eval-when-compile (current-time-string))
;; or '#.(current-time-string) in real Common Lisp
", and loaded on: "
(load-time-value (current-time-string))))
Byte-compiled, the above defun will result in the following code (or its compiled equivalent, of course) in the `.elc' file:
(setq --temp-- (current-time-string))
(defun report ()
(insert "This function was executed on: "
(current-time-string)
", compiled on: "
'"Wed Jun 23 18:33:43 1993"
", and loaded on: "
--temp--))
This section describes a feature from GNU Emacs 19 which this package makes available in other versions of Emacs.
Function: defalias symbol function
This function sets symbol's function cell to function.
It is equivalent to fset, except that in GNU Emacs 19 it also
records the setting in load-history so that it can be undone
by a later unload-feature.
In other versions of Emacs, defalias is a synonym for
fset.
This section describes functions for testing whether various facts are true or false.
The CL package defines a version of the Common Lisp typep
predicate.
Check if object is of type type, where type is a
(quoted) type name of the sort used by Common Lisp. For example,
(typep foo 'integer) is equivalent to (integerp foo).
The type argument to the above function is either a symbol or a list beginning with a symbol.
t stands for the union of all types.
(typep object t) is always true. Likewise, the
type symbol nil stands for nothing at all, and
(typep object nil) is always false.
null represents the symbol nil.
Thus (typep object 'null) is equivalent to
(null object).
real is a synonym for number, and
fixnum is a synonym for integer.
character and string-char match
integers in the range from 0 to 255.
float uses the floatp-safe predicate
defined by this package rather than floatp, so it will work
correctly even in Emacs versions without floating-point support.
(integer low high) represents all
integers between low and high, inclusive. Either bound
may be a list of a single integer to specify an exclusive limit,
or a * to specify no limit. The type (integer * *)
is thus equivalent to integer.
float, real, or
number represent numbers of that type falling in a particular
range.
and, or, and not form
combinations of types. For example, (or integer (float 0 *))
represents all objects that are integers or non-negative floats.
member or member* represent
objects eql to any of the following values. For example,
(member 1 2 3 4) is equivalent to (integer 1 4),
and (member nil) is equivalent to null.
(satisfies predicate) represent
all objects for which predicate returns true when called
with that object as an argument.
The following function and macro (not technically predicates) are
related to typep.
This function attempts to convert object to the specified
type. If object is already of that type as determined by
typep, it is simply returned. Otherwise, certain types of
conversions will be made: If type is any sequence type
(string, list, etc.) then object will be
converted to that type if possible. If type is
character, then strings of length one and symbols with
one-character names can be coerced. If type is float,
then integers can be coerced in versions of Emacs that support
floats. In all other circumstances, coerce signals an
error.
Special Form: deftype name arglist forms...
This macro defines a new type called name. It is similar
to defmacro in many ways; when name is encountered
as a type name, the body forms are evaluated and should
return a type specifier that is equivalent to the type. The
arglist is a Common Lisp argument list of the sort accepted
by defmacro*. The type specifier `(name args...)'
is expanded by calling the expander with those arguments; the type
symbol `name' is expanded by calling the expander with
no arguments. The arglist is processed the same as for
defmacro* except that optional arguments without explicit
defaults use * instead of nil as the "default"
default. Some examples:
(deftype null () '(satisfies null)) ; predefined (deftype list () '(or null cons)) ; predefined (deftype unsigned-byte (&optional bits) (list 'integer 0 (if (eq bits '*) bits (1- (lsh 1 bits))))) (unsigned-byte 8) == (integer 0 255) (unsigned-byte) == (integer 0 *) unsigned-byte == (integer 0 *)
The last example shows how the Common Lisp unsigned-byte
type specifier could be implemented if desired; this package does
not implement unsigned-byte by default.
The typecase and check-type macros also use type
names. See section Conditionals. See section Assertions and Errors. The map,
concatenate, and merge functions take type-name
arguments to specify the type of sequence to return. See section Sequences.
This package defines two Common Lisp predicates, eql and
equalp.
This function is almost the same as eq, except that if a
and b are numbers of the same type, it compares them for numeric
equality (as if by equal instead of eq). This makes a
difference only for versions of Emacs that are compiled with
floating-point support, such as Emacs 19. Emacs floats are allocated
objects just like cons cells, which means that (eq 3.0 3.0)
will not necessarily be true--if the two 3.0s were allocated
separately, the pointers will be different even though the numbers are
the same. But (eql 3.0 3.0) will always be true.
The types of the arguments must match, so (eql 3 3.0) is
still false.
Note that Emacs integers are "direct" rather than allocated, which
basically means (eq 3 3) will always be true. Thus eq
and eql behave differently only if floating-point numbers are
involved, and are indistinguishable on Emacs versions that don't
support floats.
There is a slight inconsistency with Common Lisp in the treatment of
positive and negative zeros. Some machines, notably those with IEEE
standard arithmetic, represent +0 and -0 as distinct
values. Normally this doesn't matter because the standard specifies
that (= 0.0 -0.0) should always be true, and this is indeed
what Emacs Lisp and Common Lisp do. But the Common Lisp standard
states that (eql 0.0 -0.0) and (equal 0.0 -0.0) should
be false on IEEE-like machines; Emacs Lisp does not do this, and in
fact the only known way to distinguish between the two zeros in Emacs
Lisp is to format them and check for a minus sign.
This function is a more flexible version of equal. In
particular, it compares strings case-insensitively, and it compares
numbers without regard to type (so that (equalp 3 3.0) is
true). Vectors and conses are compared recursively. All other
objects are compared as if by equal.
This function differs from Common Lisp equalp in several
respects. First, Common Lisp's equalp also compares
characters case-insensitively, which would be impractical
in this package since Emacs does not distinguish between integers
and characters. In keeping with the idea that strings are less
vector-like in Emacs Lisp, this package's equalp also will
not compare strings against vectors of integers. Finally, Common
Lisp's equalp compares hash tables without regard to
ordering, whereas this package simply compares hash tables in
terms of their underlying structure (which means vectors for Lucid
Emacs 19 hash tables, or lists for other hash tables).
Also note that the Common Lisp functions member and assoc
use eql to compare elements, whereas Emacs Lisp follows the
MacLisp tradition and uses equal for these two functions.
In Emacs, use member* and assoc* to get functions
which use eql for comparisons.
The features described in the following sections implement
various advanced control structures, including the powerful
setf facility and a number of looping and conditional
constructs.
The psetq form is just like setq, except that multiple
assignments are done in parallel rather than sequentially.
Special Form: psetq [symbol form]...
This special form (actually a macro) is used to assign to several
variables simultaneously. Given only one symbol and form,
it has the same effect as setq. Given several symbol
and form pairs, it evaluates all the forms in advance
and then stores the corresponding variables afterwards.
(setq x 2 y 3)
(setq x (+ x y) y (* x y))
x
=> 5
y ; y was computed after x was set.
=> 15
(setq x 2 y 3)
(psetq x (+ x y) y (* x y))
x
=> 5
y ; y was computed before x was set.
=> 6
The simplest use of psetq is (psetq x y y x), which
exchanges the values of two variables. (The rotatef form
provides an even more convenient way to swap two variables;
see section Modify Macros.)
psetq always returns nil.
A "generalized variable" or "place form" is one of the many places in Lisp memory where values can be stored. The simplest place form is a regular Lisp variable. But the cars and cdrs of lists, elements of arrays, properties of symbols, and many other locations are also places where Lisp values are stored.
The setf form is like setq, except that it accepts
arbitrary place forms on the left side rather than just
symbols. For example, (setf (car a) b) sets the car of
a to b, doing the same operation as (setcar a b)
but without having to remember two separate functions for setting
and accessing every type of place.
Generalized variables are analogous to "lvalues" in the C
language, where `x = a[i]' gets an element from an array
and `a[i] = x' stores an element using the same notation.
Just as certain forms like a[i] can be lvalues in C, there
is a set of forms that can be generalized variables in Lisp.
The setf macro is the most basic way to operate on generalized
variables.
Special Form: setf [place form]...
This macro evaluates form and stores it in place, which
must be a valid generalized variable form. If there are several
place and form pairs, the assignments are done sequentially
just as with setq. setf returns the value of the last
form.
The following Lisp forms will work as generalized variables, and
so may legally appear in the place argument of setf:
(setf x y) is
exactly equivalent to (setq x y), and setq itself is
strictly speaking redundant now that setf exists. Many
programmers continue to prefer setq for setting simple
variables, though, purely for stylistic or historical reasons.
The macro (setf x y) actually expands to (setq x y),
so there is no performance penalty for using it in compiled code.
car cdr caar .. cddddr nth rest first .. tenth aref elt nthcdr symbol-function symbol-value symbol-plist get get* getf gethash subseq
Note that for nthcdr and getf, the list argument
of the function must itself be a valid place form. For
example, (setf (nthcdr 0 foo) 7) will set foo itself
to 7. Note that push and pop on an nthcdr
place can be used to insert or delete at any position in a list.
The use of nthcdr as a place form is an extension
to standard Common Lisp.
setf-able.
(Some of these are defined only in Emacs 19 or only in Lucid Emacs.)
buffer-file-name marker-position buffer-modified-p match-data buffer-name mouse-position buffer-string overlay-end buffer-substring overlay-get current-buffer overlay-start current-case-table point current-column point-marker current-global-map point-max current-input-mode point-min current-local-map process-buffer current-window-configuration process-filter default-file-modes process-sentinel default-value read-mouse-position documentation-property screen-height extent-data screen-menubar extent-end-position screen-width extent-start-position selected-window face-background selected-screen face-background-pixmap selected-frame face-font standard-case-table face-foreground syntax-table face-underline-p window-buffer file-modes window-dedicated-p frame-height window-display-table frame-parameters window-height frame-visible-p window-hscroll frame-width window-point get-register window-start getenv window-width global-key-binding x-get-cut-buffer keymap-parent x-get-cutbuffer local-key-binding x-get-secondary-selection mark x-get-selection mark-marker
Most of these have directly corresponding "set" functions, like
use-local-map for current-local-map, or goto-char
for point. A few, like point-min, expand to longer
sequences of code when they are setf'd ((narrow-to-region
x (point-max)) in this case).
(substring subplace n [m]),
where subplace is itself a legal generalized variable whose
current value is a string, and where the value stored is also a
string. The new string is spliced into the specified part of the
destination string. For example:
(setq a (list "hello" "world"))
=> ("hello" "world")
(cadr a)
=> "world"
(substring (cadr a) 2 4)
=> "rl"
(setf (substring (cadr a) 2 4) "o")
=> "o"
(cadr a)
=> "wood"
a
=> ("hello" "wood")
The generalized variable buffer-substring, listed above,
also works in this way by replacing a portion of the current buffer.
(apply 'func ...) or
(apply (function func) ...), where func
is a setf-able function whose store function is "suitable"
in the sense described in Steele's book; since none of the standard
Emacs place functions are suitable in this sense, this feature is
only interesting when used with places you define yourself with
define-setf-method or the long form of defsetf.
setf
is applied to the resulting form.
defsetf or define-setf-method
has been made.
Using any forms other than these in the place argument to
setf will signal an error.
The setf macro takes care to evaluate all subforms in
the proper left-to-right order; for example,
(setf (aref vec (incf i)) i)
looks like it will evaluate (incf i) exactly once, before the
following access to i; the setf expander will insert
temporary variables as necessary to ensure that it does in fact work
this way no matter what setf-method is defined for aref.
(In this case, aset would be used and no such steps would
be necessary since aset takes its arguments in a convenient
order.)
However, if the place form is a macro which explicitly evaluates its arguments in an unusual order, this unusual order will be preserved. Adapting an example from Steele, given
(defmacro wrong-order (x y) (list 'aref y x))
the form (setf (wrong-order a b) 17) will
evaluate b first, then a, just as in an actual call
to wrong-order.
This package defines a number of other macros besides setf
that operate on generalized variables. Many are interesting and
useful even when the place is just a variable name.
Special Form: psetf [place form]...
This macro is to setf what psetq is to setq:
When several places and forms are involved, the
assignments take place in parallel rather than sequentially.
Specifically, all subforms are evaluated from left to right, then
all the assignments are done (in an undefined order).
Special Form: incf place &optional x
This macro increments the number stored in place by one, or
by x if specified. The incremented value is returned. For
example, (incf i) is equivalent to (setq i (1+ i)), and
(incf (car x) 2) is equivalent to (setcar x (+ (car x) 2)).
Once again, care is taken to preserve the "apparent" order of evaluation. For example,
(incf (aref vec (incf i)))
appears to increment i once, then increment the element of
vec addressed by i; this is indeed exactly what it
does, which means the above form is not equivalent to the
"obvious" expansion,
(setf (aref vec (incf i)) (1+ (aref vec (incf i)))) ; Wrong!
but rather to something more like
(let ((temp (incf i))) (setf (aref vec temp) (1+ (aref vec temp))))
Again, all of this is taken care of automatically by incf and
the other generalized-variable macros.
As a more Emacs-specific example of incf, the expression
(incf (point) n) is essentially equivalent to
(forward-char n).
Special Form: decf place &optional x
This macro decrements the number stored in place by one, or by x if specified.
This macro removes and returns the first element of the list stored
in place. It is analogous to (prog1 (car place)
(setf place (cdr place))), except that it takes care
to evaluate all subforms only once.
This macro inserts x at the front of the list stored in
place. It is analogous to (setf place (cons
x place)), except for evaluation of the subforms.
Special Form: pushnew x place &key :test :test-not :key
This macro inserts x at the front of the list stored in
place, but only if x was not eql to any
existing element of the list. The optional keyword arguments
are interpreted in the same way as for adjoin.
See section Lists as Sets.
Special Form: shiftf place... newvalue
This macro shifts the places left by one, shifting in the
value of newvalue (which may be any Lisp expression, not just
a generalized variable), and returning the value shifted out of
the first place. Thus, (shiftf a b c
d) is equivalent to
(prog1
a
(psetf a b
b c
c d))
except that the subforms of a, b, and c are actually evaluated only once each and in the apparent order.
Special Form: rotatef place...
This macro rotates the places left by one in circular fashion.
Thus, (rotatef a b c d) is equivalent to
(psetf a b
b c
c d
d a)
except for the evaluation of subforms. rotatef always
returns nil. Note that (rotatef a b)
conveniently exchanges a and b.
The following macros were invented for this package; they have no analogues in Common Lisp.
Special Form: letf (bindings...) forms...
This macro is analogous to let, but for generalized variables
rather than just symbols. Each binding should be of the form
(place value); the original contents of the
places are saved, the values are stored in them, and
then the body forms are executed. Afterwards, the places
are set back to their original saved contents. This cleanup happens
even if the forms exit irregularly due to a throw or an
error.
For example,
(letf (((point) (point-min))
(a 17))
...)
moves "point" in the current buffer to the beginning of the buffer,
and also binds a to 17 (as if by a normal let, since
a is just a regular variable). After the body exits, a
is set back to its original value and point is moved back to its
original position.
Note that letf on (point) is not quite like a
save-excursion, as the latter effectively saves a marker
which tracks insertions and deletions in the buffer. Actually,
a letf of (point-marker) is much closer to this
behavior. (point and point-marker are equivalent
as setf places; each will accept either an integer or a
marker as the stored value.)
Since generalized variables look like lists, let's shorthand
of using `foo' for `(foo nil)' as a binding would
be ambiguous in letf and is not allowed.
However, a binding specifier may be a one-element list
`(place)', which is similar to `(place
place)'. In other words, the place is not disturbed
on entry to the body, and the only effect of the letf is
to restore the original value of place afterwards. (The
redundant access-and-store suggested by the (place
place) example does not actually occur.)
In most cases, the place must have a well-defined value on
entry to the letf form. The only exceptions are plain
variables and calls to symbol-value and symbol-function.
If the symbol is not bound on entry, it is simply made unbound by
makunbound or fmakunbound on exit.
Special Form: letf* (bindings...) forms...
This macro is to letf what let* is to let:
It does the bindings in sequential rather than parallel order.
Special Form: callf function place args...
This is the "generic" modify macro. It calls function,
which should be an unquoted function name, macro name, or lambda.
It passes place and args as arguments, and assigns the
result back to place. For example, (incf place
n) is the same as (callf + place n).
Some more examples:
(callf abs my-number) (callf concat (buffer-name) "<" (int-to-string n) ">") (callf union happy-people (list joe bob) :test 'same-person)
See section Customizing Setf, for define-modify-macro, a way
to create even more concise notations for modify macros. Note
again that callf is an extension to standard Common Lisp.
Special Form: callf2 function arg1 place args...
This macro is like callf, except that place is
the second argument of function rather than the
first. For example, (push x place) is
equivalent to (callf2 cons x place).
The callf and callf2 macros serve as building
blocks for other macros like incf, pushnew, and
define-modify-macro. The letf and letf*
macros are used in the processing of symbol macros;
see section Macro Bindings.
Common Lisp defines three macros, define-modify-macro,
defsetf, and define-setf-method, that allow the
user to extend generalized variables in various ways.
Special Form: define-modify-macro name arglist function [doc-string]
This macro defines a "read-modify-write" macro similar to
incf and decf. The macro name is defined
to take a place argument followed by additional arguments
described by arglist. The call
(name place args...)
will be expanded to
(callf func place args...)
which in turn is roughly equivalent to
(setf place (func place args...))
For example:
(define-modify-macro incf (&optional (n 1)) +) (define-modify-macro concatf (&rest args) concat)
Note that &key is not allowed in arglist, but
&rest is sufficient to pass keywords on to the function.
Most of the modify macros defined by Common Lisp do not exactly
follow the pattern of define-modify-macro. For example,
push takes its arguments in the wrong order, and pop
is completely irregular. You can define these macros "by hand"
using get-setf-method, or consult the source file
`cl-macs.el' to see how to use the internal setf
building blocks.
Special Form: defsetf access-fn update-fn
This is the simpler of two defsetf forms. Where
access-fn is the name of a function which accesses a place,
this declares update-fn to be the corresponding store
function. From now on,
(setf (access-fn arg1 arg2 arg3) value)
will be expanded to
(update-fn arg1 arg2 arg3 value)
The update-fn is required to be either a true function, or
a macro which evaluates its arguments in a function-like way. Also,
the update-fn is expected to return value as its result.
Otherwise, the above expansion would not obey the rules for the way
setf is supposed to behave.
As a special (non-Common-Lisp) extension, a third argument of t
to defsetf says that the update-fn's return value is
not suitable, so that the above setf should be expanded to
something more like
(let ((temp value)) (update-fn arg1 arg2 arg3 temp) temp)
Some examples of the use of defsetf, drawn from the standard
suite of setf methods, are:
(defsetf car setcar) (defsetf symbol-value set) (defsetf buffer-name rename-buffer t)
Special Form: defsetf access-fn arglist (store-var) forms...
This is the second, more complex, form of defsetf. It is
rather like defmacro except for the additional store-var
argument. The forms should return a Lisp form which stores
the value of store-var into the generalized variable formed
by a call to access-fn with arguments described by arglist.
The forms may begin with a string which documents the setf
method (analogous to the doc string that appears at the front of a
function).
For example, the simple form of defsetf is shorthand for
(defsetf access-fn (&rest args) (store) (append '(update-fn) args (list store)))
The Lisp form that is returned can access the arguments from
arglist and store-var in an unrestricted fashion;
macros like setf and incf which invoke this
setf-method will insert temporary variables as needed to make
sure the apparent order of evaluation is preserved.
Another example drawn from the standard package:
(defsetf nth (n x) (store) (list 'setcar (list 'nthcdr n x) store))
Special Form: define-setf-method access-fn arglist forms...
This is the most general way to create new place forms. When
a setf to access-fn with arguments described by
arglist is expanded, the forms are evaluated and
must return a list of five items:
gensym).
This is exactly like the Common Lisp macro of the same name, except that the method returns a list of five values rather than the five values themselves, since Emacs Lisp does not support Common Lisp's notion of multiple return values.
Once again, the forms may begin with a documentation string.
A setf-method should be maximally conservative with regard to
temporary variables. In the setf-methods generated by
defsetf, the second return value is simply the list of
arguments in the place form, and the first return value is a
list of a corresponding number of temporary variables generated
by gensym. Macros like setf and incf which
use this setf-method will optimize away most temporaries that
turn out to be unnecessary, so there is little reason for the
setf-method itself to optimize.
Function: get-setf-method place &optional env
This function returns the setf-method for place, by
invoking the definition previously recorded by defsetf
or define-setf-method. The result is a list of five
values as described above. You can use this function to build
your own incf-like modify macros. (Actually, it is
better to use the internal functions cl-setf-do-modify
and cl-setf-do-store, which are a bit easier to use and
which also do a number of optimizations; consult the source
code for the incf function for a simple example.)
The argument env specifies the "environment" to be
passed on to macroexpand if get-setf-method should
need to expand a macro in place. It should come from
an &environment argument to the macro or setf-method
that called get-setf-method.
See also the source code for the setf-methods for apply
and substring, each of which works by calling
get-setf-method on a simpler case, then massaging
the result in various ways.
Modern Common Lisp defines a second, independent way to specify
the setf behavior of a function, namely "setf
functions" whose names are lists (setf name)
rather than symbols. For example, (defun (setf foo) ...)
defines the function that is used when setf is applied to
foo. This package does not currently support setf
functions. In particular, it is a compile-time error to use
setf on a form which has not already been defsetf'd
or otherwise declared; in newer Common Lisps, this would not be
an error since the function (setf func) might be
defined later.
@secno=4
These Lisp forms make bindings to variables and function names,
analogous to Lisp's built-in let form.
See section Modify Macros, for the letf and letf* forms which
are also related to variable bindings.
The standard let form binds variables whose names are known
at compile-time. The progv form provides an easy way to
bind variables whose names are computed at run-time.
Special Form: progv symbols values forms...
This form establishes let-style variable bindings on a
set of variables computed at run-time. The expressions
symbols and values are evaluated, and must return lists
of symbols and values, respectively. The symbols are bound to the
corresponding values for the duration of the body forms.
If values is shorter than symbols, the last few symbols
are made unbound (as if by makunbound) inside the body.
If symbols is shorter than values, the excess values
are ignored.
The CL package defines the following macro which
more closely follows the Common Lisp let form:
Special Form: lexical-let (bindings...) forms...
This form is exactly like let except that the bindings it
establishes are purely lexical. Lexical bindings are similar to
local variables in a language like C: Only the code physically
within the body of the lexical-let (after macro expansion)
may refer to the bound variables.
(setq a 5)
(defun foo (b) (+ a b))
(let ((a 2)) (foo a))
=> 4
(lexical-let ((a 2)) (foo a))
=> 7
In this example, a regular let binding of a actually
makes a temporary change to the global variable a, so foo
is able to see the binding of a to 2. But lexical-let
actually creates a distinct local variable a for use within its
body, without any effect on the global variable of the same name.
The most important use of lexical bindings is to create closures. A closure is a function object that refers to an outside lexical variable. For example:
(defun make-adder (n)
(lexical-let ((n n))
(function (lambda (m) (+ n m)))))
(setq add17 (make-adder 17))
(funcall add17 4)
=> 21
The call (make-adder 17) returns a function object which adds
17 to its argument. If let had been used instead of
lexical-let, the function object would have referred to the
global n, which would have been bound to 17 only during the
call to make-adder itself.
(defun make-counter ()
(lexical-let ((n 0))
(function* (lambda (&optional (m 1)) (incf n m)))))
(setq count-1 (make-counter))
(funcall count-1 3)
=> 3
(funcall count-1 14)
=> 17
(setq count-2 (make-counter))
(funcall count-2 5)
=> 5
(funcall count-1 2)
=> 19
(funcall count-2)
=> 6
Here we see that each call to make-counter creates a distinct
local variable n, which serves as a private counter for the
function object that is returned.
Closed-over lexical variables persist until the last reference to
them goes away, just like all other Lisp objects. For example,
count-2 refers to a function object which refers to an
instance of the variable n; this is the only reference
to that variable, so after (setq count-2 nil) the garbage
collector would be able to delete this instance of n.
Of course, if a lexical-let does not actually create any
closures, then the lexical variables are free as soon as the
lexical-let returns.
Many closures are used only during the extent of the bindings they
refer to; these are known as "downward funargs" in Lisp parlance.
When a closure is used in this way, regular Emacs Lisp dynamic
bindings suffice and will be more efficient than lexical-let
closures:
(defun add-to-list (x list)
(mapcar (function (lambda (y) (+ x y))) list))
(add-to-list 7 '(1 2 5))
=> (8 9 12)
Since this lambda is only used while x is still bound,
it is not necessary to make a true closure out of it.
You can use defun or flet inside a lexical-let
to create a named closure. If several closures are created in the
body of a single lexical-let, they all close over the same
instance of the lexical variable.
The lexical-let form is an extension to Common Lisp. In
true Common Lisp, all bindings are lexical unless declared otherwise.
Special Form: lexical-let* (bindings...) forms...
This form is just like lexical-let, except that the bindings
are made sequentially in the manner of let*.
These forms make let-like bindings to functions instead
of variables.
Special Form: flet (bindings...) forms...
This form establishes let-style bindings on the function
cells of symbols rather than on the value cells. Each binding
must be a list of the form `(name arglist
forms...)', which defines a function exactly as if
it were a defun* form. The function name is defined
accordingly for the duration of the body of the flet; then
the old function definition, or lack thereof, is restored.
While flet in Common Lisp establishes a lexical binding of
name, Emacs Lisp flet makes a dynamic binding. The
result is that flet affects indirect calls to a function as
well as calls directly inside the flet form itself.
You can use flet to disable or modify the behavior of a
function in a temporary fashion. This will even work on Emacs
primitives, although note that some calls to primitive functions
internal to Emacs are made without going through the symbol's
function cell, and so will not be affected by flet. For
example,
(flet ((message (&rest args) (push args saved-msgs))) (do-something))
This code attempts to replace the built-in function message
with a function that simply saves the messages in a list rather
than displaying them. The original definition of message
will be restored after do-something exits. This code will
work fine on messages generated by other Lisp code, but messages
generated directly inside Emacs will not be caught since they make
direct C-language calls to the message routines rather than going
through the Lisp message function.
Functions defined by flet may use the full Common Lisp
argument notation supported by defun*; also, the function
body is enclosed in an implicit block as if by defun*.
See section Program Structure.
Special Form: labels (bindings...) forms...
The labels form is a synonym for flet. (In Common
Lisp, labels and flet differ in ways that depend on
their lexical scoping; these distinctions vanish in dynamically
scoped Emacs Lisp.)
These forms create local macros and "symbol macros."
Special Form: macrolet (bindings...) forms...
This form is analogous to flet, but for macros instead of
functions. Each binding is a list of the same form as the
arguments to defmacro* (i.e., a macro name, argument list,
and macro-expander forms). The macro is defined accordingly for
use within the body of the macrolet.
Because of the nature of macros, macrolet is lexically
scoped even in Emacs Lisp: The macrolet binding will
affect only calls that appear physically within the body
forms, possibly after expansion of other macros in the
body.
Special Form: symbol-macrolet (bindings...) forms...
This form creates symbol macros, which are macros that look like variable references rather than function calls. Each binding is a list `(var expansion)'; any reference to var within the body forms is replaced by expansion.
(setq bar '(5 . 9))
(symbol-macrolet ((foo (car bar)))
(incf foo))
bar
=> (6 . 9)
A setq of a symbol macro is treated the same as a setf.
I.e., (setq foo 4) in the above would be equivalent to
(setf foo 4), which in turn expands to (setf (car bar) 4).
Likewise, a let or let* binding a symbol macro is
treated like a letf or letf*. This differs from true
Common Lisp, where the rules of lexical scoping cause a let
binding to shadow a symbol-macrolet binding. In this package,
only lexical-let and lexical-let* will shadow a symbol
macro.
There is no analogue of defmacro for symbol macros; all symbol
macros are local. A typical use of symbol-macrolet is in the
expansion of another macro:
(defmacro* my-dolist ((x list) &rest body)
(let ((var (gensym)))
(list 'loop 'for var 'on list 'do
(list* 'symbol-macrolet (list (list x (list 'car var)))
body))))
(setq mylist '(1 2 3 4))
(my-dolist (x mylist) (incf x))
mylist
=> (2 3 4 5)
In this example, the my-dolist macro is similar to dolist
(see section Iteration) except that the variable x becomes a true
reference onto the elements of the list. The my-dolist call
shown here expands to
(loop for G1234 on mylist do
(symbol-macrolet ((x (car G1234)))
(incf x)))
which in turn expands to
(loop for G1234 on mylist do (incf (car G1234)))
See section Loop Facility, for a description of the loop macro.
This package defines a nonstandard in-ref loop clause that
works much like my-dolist.
These conditional forms augment Emacs Lisp's simple if,
and, or, and cond forms.
Special Form: when test forms...
This is a variant of if where there are no "else" forms,
and possibly several "then" forms. In particular,
(when test a b c)
is entirely equivalent to
(if test (progn a b c) nil)
Special Form: unless test forms...
This is a variant of if where there are no "then" forms,
and possibly several "else" forms:
(unless test a b c)
is entirely equivalent to
(when (not test) a b c)
Special Form: case keyform clause...
This macro evaluates keyform, then compares it with the key
values listed in the various clauses. Whichever clause matches
the key is executed; comparison is done by eql. If no clause
matches, the case form returns nil. The clauses are
of the form
(keylist body-forms...)
where keylist is a list of key values. If there is exactly
one value, and it is not a cons cell or the symbol nil or
t, then it can be used by itself as a keylist without
being enclosed in a list. All key values in the case form
must be distinct. The final clauses may use t in place of
a keylist to indicate a default clause that should be taken
if none of the other clauses match. (The symbol otherwise
is also recognized in place of t. To make a clause that
matches the actual symbol t, nil, or otherwise,
enclose the symbol in a list.)
For example, this expression reads a keystroke, then does one of four things depending on whether it is an `a', a `b', a RET or LFD, or anything else.
(case (read-char) (?a (do-a-thing)) (?b (do-b-thing)) ((?\r ?\n) (do-ret-thing)) (t (do-other-thing)))
Special Form: ecase keyform clause...
This macro is just like case, except that if the key does
not match any of the clauses, an error is signalled rather than
simply returning nil.
Special Form: typecase keyform clause...
This macro is a version of case that checks for types
rather than values. Each clause is of the form
`(type body...)'. See section Type Predicates,
for a description of type specifiers. For example,
(typecase x (integer (munch-integer x)) (float (munch-float x)) (string (munch-integer (string-to-int x))) (t (munch-anything x)))
The type specifier t matches any type of object; the word
otherwise is also allowed. To make one clause match any of
several types, use an (or ...) type specifier.
Special Form: etypecase keyform clause...
This macro is just like typecase, except that if the key does
not match any of the clauses, an error is signalled rather than
simply returning nil.
Common Lisp blocks provide a non-local exit mechanism very
similar to catch and throw, but lexically rather than
dynamically scoped. This package actually implements block
in terms of catch; however, the lexical scoping allows the
optimizing byte-compiler to omit the costly catch step if the
body of the block does not actually return-from the block.
Special Form: block name forms...
The forms are evaluated as if by a progn. However,
if any of the forms execute (return-from name),
they will jump out and return directly from the block form.
The block returns the result of the last form unless
a return-from occurs.
The block/return-from mechanism is quite similar to
the catch/throw mechanism. The main differences are
that block names are unevaluated symbols, rather than forms
(such as quoted symbols) which evaluate to a tag at run-time; and
also that blocks are lexically scoped whereas catch/throw
are dynamically scoped. This means that functions called from the
body of a catch can also throw to the catch,
but the return-from referring to a block name must appear
physically within the forms that make up the body of the block.
They may not appear within other called functions, although they may
appear within macro expansions or lambdas in the body. Block
names and catch names form independent name-spaces.
In true Common Lisp, defun and defmacro surround
the function or expander bodies with implicit blocks with the
same name as the function or macro. This does not occur in Emacs
Lisp, but this package provides defun* and defmacro*
forms which do create the implicit block.
The Common Lisp looping constructs defined by this package,
such as loop and dolist, also create implicit blocks
just as in Common Lisp.
Because they are implemented in terms of Emacs Lisp catch
and throw, blocks have the same overhead as actual
catch constructs (roughly two function calls). However,
Zawinski and Furuseth's optimizing byte compiler (standard in
Emacs 19) will optimize away the catch if the block does
not in fact contain any return or return-from calls
that jump to it. This means that do loops and defun*
functions which don't use return don't pay the overhead to
support it.
Special Form: return-from name [result]
This macro returns from the block named name, which must be
an (unevaluated) symbol. If a result form is specified, it
is evaluated to produce the result returned from the block.
Otherwise, nil is returned.
This macro is exactly like (return-from nil result).
Common Lisp loops like do and dolist implicitly enclose
themselves in nil blocks.
The macros described here provide more sophisticated, high-level
looping constructs to complement Emacs Lisp's basic while
loop.
The CL package supports both the simple, old-style meaning of
loop and the extremely powerful and flexible feature known as
the Loop Facility or Loop Macro. This more advanced
facility is discussed in the following section; see section Loop Facility.
The simple form of loop is described here.
If loop is followed by zero or more Lisp expressions,
then (loop exprs...) simply creates an infinite
loop executing the expressions over and over. The loop is
enclosed in an implicit nil block. Thus,
(loop (foo) (if (no-more) (return 72)) (bar))
is exactly equivalent to
(block nil (while t (foo) (if (no-more) (return 72)) (bar)))
If any of the expressions are plain symbols, the loop is instead interpreted as a Loop Macro specification as described later. (This is not a restriction in practice, since a plain symbol in the above notation would simply access and throw away the value of a variable.)
Special Form: do (spec...) (end-test [result...]) forms...
This macro creates a general iterative loop. Each spec is of the form
(var [init [step]])
The loop works as follows: First, each var is bound to the
associated init value as if by a let form. Then, in
each iteration of the loop, the end-test is evaluated; if
true, the loop is finished. Otherwise, the body forms are
evaluated, then each var is set to the associated step
expression (as if by a psetq form) and the next iteration
begins. Once the end-test becomes true, the result
forms are evaluated (with the vars still bound to their
values) to produce the result returned by do.
The entire do loop is enclosed in an implicit nil
block, so that you can use (return) to break out of the
loop at any time.
If there are no result forms, the loop returns nil.
If a given var has no step form, it is bound to its
init value but not otherwise modified during the do
loop (unless the code explicitly modifies it); this case is just
a shorthand for putting a (let ((var init)) ...)
around the loop. If init is also omitted it defaults to
nil, and in this case a plain `var' can be used
in place of `(var)', again following the analogy with
let.
This example (from Steele) illustrates a loop which applies the
function f to successive pairs of values from the lists
foo and bar; it is equivalent to the call
(mapcar* 'f foo bar). Note that this loop has no body
forms at all, performing all its work as side effects of
the rest of the loop.
(do ((x foo (cdr x))
(y bar (cdr y))
(z nil (cons (f (car x) (car y)) z)))
((or (null x) (null y))
(nreverse z)))
Special Form: do* (spec...) (end-test [result...]) forms...
This is to do what let* is to let. In
particular, the initial values are bound as if by let*
rather than let, and the steps are assigned as if by
setq rather than psetq.
Here is another way to write the above loop:
(do* ((xp foo (cdr xp))
(yp bar (cdr yp))
(x (car xp) (car xp))
(y (car yp) (car yp))
z)
((or (null xp) (null yp))
(nreverse z))
(push (f x y) z))
Special Form: dolist (var list [result]) forms...
This is a more specialized loop which iterates across the elements
of a list. list should evaluate to a list; the body forms
are executed with var bound to each element of the list in
turn. Finally, the result form (or nil) is evaluated
with var bound to nil to produce the result returned by
the loop. The loop is surrounded by an implicit nil block.
Special Form: dotimes (var count [result]) forms...
This is a more specialized loop which iterates a specified number
of times. The body is executed with var bound to the integers
from zero (inclusive) to count (exclusive), in turn. Then
the result form is evaluated with var bound to the total
number of iterations that were done (i.e., (max 0 count))
to get the return value for the loop form. The loop is surrounded
by an implicit nil block.
Special Form: do-symbols (var [obarray [result]]) forms...
This loop iterates over all interned symbols. If obarray
is specified and is not nil, it loops over all symbols in
that obarray. For each symbol, the body forms are evaluated
with var bound to that symbol. The symbols are visited in
an unspecified order. Afterward the result form, if any,
is evaluated (with var bound to nil) to get the return
value. The loop is surrounded by an implicit nil block.
Special Form: do-all-symbols (var [result]) forms...
This is identical to do-symbols except that the obarray
argument is omitted; it always iterates over the default obarray.
See section Mapping over Sequences, for some more functions for iterating over vectors or lists.
A common complaint with Lisp's traditional looping constructs is
that they are either too simple and limited, such as Common Lisp's
dotimes or Emacs Lisp's while, or too unreadable and
obscure, like Common Lisp's do loop.
To remedy this, recent versions of Common Lisp have added a new
construct called the "Loop Facility" or "loop macro,"
with an easy-to-use but very powerful and expressive syntax.
The loop macro essentially creates a mini-language within
Lisp that is specially tailored for describing loops. While this
language is a little strange-looking by the standards of regular Lisp,
it turns out to be very easy to learn and well-suited to its purpose.
Since loop is a macro, all parsing of the loop language
takes place at byte-compile time; compiled loops are just
as efficient as the equivalent while loops written longhand.
A loop construct consists of a series of clauses, each
introduced by a symbol like for or do. Clauses
are simply strung together in the argument list of loop,
with minimal extra parentheses. The various types of clauses
specify initializations, such as the binding of temporary
variables, actions to be taken in the loop, stepping actions,
and final cleanup.
Common Lisp specifies a certain general order of clauses in a loop:
(loop name-clause
var-clauses...
action-clauses...)
The name-clause optionally gives a name to the implicit
block that surrounds the loop. By default, the implicit block
is named nil. The var-clauses specify what
variables should be bound during the loop, and how they should
be modified or iterated throughout the course of the loop. The
action-clauses are things to be done during the loop, such
as computing, collecting, and returning values.
The Emacs version of the loop macro is less restrictive about
the order of clauses, but things will behave most predictably if
you put the variable-binding clauses with, for, and
repeat before the action clauses. As in Common Lisp,
initially and finally clauses can go anywhere.
Loops generally return nil by default, but you can cause
them to return a value by using an accumulation clause like
collect, an end-test clause like always, or an
explicit return clause to jump out of the implicit block.
(Because the loop body is enclosed in an implicit block, you can
also use regular Lisp return or return-from to
break out of the loop.)
The following sections give some examples of the Loop Macro in
action, and describe the particular loop clauses in great detail.
Consult the second edition of Steele's Common Lisp, the Language,
for additional discussion and examples of the loop macro.
Before listing the full set of clauses that are allowed, let's
look at a few example loops just to get a feel for the loop
language.
(loop for buf in (buffer-list)
collect (buffer-file-name buf))
This loop iterates over all Emacs buffers, using the list
returned by buffer-list. For each buffer buf,
it calls buffer-file-name and collects the results into
a list, which is then returned from the loop construct.
The result is a list of the file names of all the buffers in
Emacs' memory. The words for, in, and collect
are reserved words in the loop language.
(loop repeat 20 do (insert "Yowsa\n"))
This loop inserts the phrase "Yowsa" twenty times in the current buffer.
(loop until (eobp) do (munch-line) (forward-line 1))
This loop calls munch-line on every line until the end
of the buffer. If point is already at the end of the buffer,
the loop exits immediately.
(loop do (munch-line) until (eobp) do (forward-line 1))
This loop is similar to the above one, except that munch-line
is always called at least once.
(loop for x from 1 to 100
for y = (* x x)
until (>= y 729)
finally return (list x (= y 729)))
This more complicated loop searches for a number x whose
square is 729. For safety's sake it only examines x
values up to 100; dropping the phrase `to 100' would
cause the loop to count upwards with no limit. The second
for clause defines y to be the square of x
within the loop; the expression after the = sign is
reevaluated each time through the loop. The until
clause gives a condition for terminating the loop, and the
finally clause says what to do when the loop finishes.
(This particular example was written less concisely than it
could have been, just for the sake of illustration.)
Note that even though this loop contains three clauses (two
fors and an until) that would have been enough to
define loops all by themselves, it still creates a single loop
rather than some sort of triple-nested loop. You must explicitly
nest your loop constructs if you want nested loops.
Most loops are governed by one or more for clauses.
A for clause simultaneously describes variables to be
bound, how those variables are to be stepped during the loop,
and usually an end condition based on those variables.
The word as is a synonym for the word for. This
word is followed by a variable name, then a word like from
or across that describes the kind of iteration desired.
In Common Lisp, the phrase being the sometimes precedes
the type of iteration; in this package both being and
the are optional. The word each is a synonym
for the, and the word that follows it may be singular
or plural: `for x being the elements of y' or
`for x being each element of y'. Which form you use
is purely a matter of style.
The variable is bound around the loop as if by let:
(setq i 'happy)
(loop for i from 1 to 10 do (do-something-with i))
i
=> happy
for var from expr1 to expr2 by expr3
for clause creates a counting loop. Each of
the three sub-terms is optional, though there must be at least one
term so that the clause is marked as a counting clause.
The three expressions are the starting value, the ending value, and
the step value, respectively, of the variable. The loop counts
upwards by default (expr3 must be positive), from expr1
to expr2 inclusively. If you omit the from term, the
loop counts from zero; if you omit the to term, the loop
counts forever without stopping (unless stopped by some other
loop clause, of course); if you omit the by term, the loop
counts in steps of one.
You can replace the word from with upfrom or
downfrom to indicate the direction of the loop. Likewise,
you can replace to with upto or downto.
For example, `for x from 5 downto 1' executes five times
with x taking on the integers from 5 down to 1 in turn.
Also, you can replace to with below or above,
which are like upto and downto respectively except
that they are exclusive rather than inclusive limits:
(loop for x to 10 collect x)
=> (0 1 2 3 4 5 6 7 8 9 10)
(loop for x below 10 collect x)
=> (0 1 2 3 4 5 6 7 8 9)
The by value is always positive, even for downward-counting
loops. Some sort of from value is required for downward
loops; `for x downto 5' is not a legal loop clause all by
itself.
for var in list by function
by term, then function
is used to traverse the list instead of cdr; it must be a
function taking one argument. For example:
(loop for x in '(1 2 3 4 5 6) collect (* x x))
=> (1 4 9 16 25 36)
(loop for x in '(1 2 3 4 5 6) by 'cddr collect (* x x))
=> (1 9 25)
for var on list by function
(loop for x on '(1 2 3 4) collect x)
=> ((1 2 3 4) (2 3 4) (3 4) (4))
With by, there is no real reason that the on expression
must be a list. For example:
(loop for x on first-animal by 'next-animal collect x)
where (next-animal x) takes an "animal" x and returns
the next in the (assumed) sequence of animals, or nil if
x was the last animal in the sequence.
for var in-ref list by function
in clause, but var becomes
a setf-able "reference" onto the elements of the list
rather than just a temporary variable. For example,
(loop for x in-ref my-list do (incf x))
increments every element of my-list in place. This clause
is an extension to standard Common Lisp.
for var across array
(loop for x across "aeiou"
do (use-vowel (char-to-string x)))
for var across-ref array
setf-able
reference onto the elements; see in-ref above.
for var being the elements of sequence
in or
across. The clause may be followed by the additional term
`using (index var2)' to cause var2 to be bound to
the successive indices (starting at 0) of the elements.
This clause type is taken from older versions of the loop macro,
and is not present in modern Common Lisp. The `using (sequence ...)'
term of the older macros is not supported.
for var being the elements of-ref sequence
setf-able
reference onto the elements; see in-ref above.
for var being the symbols [of obarray]
As an example,
(loop for sym being the symbols
when (fboundp sym)
when (string-match "^map" (symbol-name sym))
collect sym)
returns a list of all the functions whose names begin with `map'.
The Common Lisp words external-symbols and present-symbols
are also recognized but are equivalent to symbols in Emacs Lisp.
Due to a minor implementation restriction, it will not work to have
more than one for clause iterating over symbols, hash tables,
keymaps, overlays, or intervals in a given loop. Fortunately,
it would rarely if ever be useful to do so. It is legal to mix
one of these types of clauses with other clauses like for ... to
or while.
for var being the hash-keys of hash-table
hash-values
is the opposite word of the word following the) to cause
var and var2 to be bound to the two parts of each
hash table entry.
for var being the key-codes of keymap
using
clause to access both the codes and the bindings together.
for var being the key-seqs of keymap
for var being the overlays [of buffer] ...
extents is synonymous
with overlays). Under Emacs 18, this clause iterates zero
times. If the of term is omitted, the current buffer is used.
This clause also accepts optional `from pos' and
`to pos' terms, limiting the clause to overlays which
overlap the specified region.
for var being the intervals [of buffer] ...
of,
from, to, and property terms, where the latter
term restricts the search to just the specified property. The
of term may specify either a buffer or a string. This
clause is useful only in GNU Emacs 19; in other versions, all
buffers and strings consist of a single interval.
for var being the frames
screens is a synonym for frames. The frames
are visited in next-frame order starting from
selected-frame.
for var being the windows [of frame]
of term is not
allowed there.)
for var being the buffers
for var = expr1 then expr2
(loop for x on my-list by 'cddr do ...) (loop for x = my-list then (cddr x) while x do ...)
Note that this type of for clause does not imply any sort
of terminating condition; the above example combines it with a
while clause to tell when to end the loop.
If you omit the then term, expr1 is used both for
the initial setting and for successive settings:
(loop for x = (random) when (> x 0) return x)
This loop keeps taking random numbers from the (random)
function until it gets a positive one, which it then returns.
If you include several for clauses in a row, they are
treated sequentially (as if by let* and setq).
You can instead use the word and to link the clauses,
in which case they are processed in parallel (as if by let
and psetq).
(loop for x below 5 for y = nil then x collect (list x y))
=> ((0 nil) (1 1) (2 2) (3 3) (4 4))
(loop for x below 5 and y = nil then x collect (list x y))
=> ((0 nil) (1 0) (2 1) (3 2) (4 3))
In the first loop, y is set based on the value of x
that was just set by the previous clause; in the second loop,
x and y are set simultaneously so y is set
based on the value of x left over from the previous time
through the loop.
Another feature of the loop macro is destructuring,
similar in concept to the destructuring provided by defmacro.
The var part of any for clause can be given as a list
of variables instead of a single variable. The values produced
during loop execution must be lists; the values in the lists are
stored in the corresponding variables.
(loop for (x y) in '((2 3) (4 5) (6 7)) collect (+ x y))
=> (5 9 13)
In loop destructuring, if there are more values than variables
the trailing values are ignored, and if there are more variables
than values the trailing variables get the value nil.
If nil is used as a variable name, the corresponding
values are ignored. Destructuring may be nested, and dotted
lists of variables like (x . y) are allowed.
Aside from for clauses, there are several other loop clauses
that control the way the loop operates. They might be used by
themselves, or in conjunction with one or more for clauses.
repeat integer
(loop repeat n do ...) (loop for temp to n do ...)
are identical except that the second one forces you to choose a name for a variable you aren't actually going to use.
while condition
nil. For example, the following two
loops are equivalent, except for the implicit nil block
that surrounds the second one:
(while cond forms...) (loop while cond do forms...)
until condition
nil.
always condition
nil.
Unlike while, it stops the loop using return nil so that
the finally clauses are not executed. If all the conditions
were non-nil, the loop returns t:
(if (loop for size in size-list always (> size 10))
(some-big-sizes)
(no-big-sizes))
never condition
always, except that the loop returns
t if any conditions were false, or nil otherwise.
thereis condition
nil;
in this case, it returns that non-nil value. If all the
values were nil, the loop returns nil.
These clauses cause the loop to accumulate information about the
specified Lisp form. The accumulated result is returned
from the loop unless overridden, say, by a return clause.
collect form
collect appear elsewhere in this manual.
The word collecting is a synonym for collect, and
likewise for the other accumulation clauses.
append form
append.
nconc form
concat form
vconcat form
count form
nil value.
sum form
maximize form
maximize is executed zero times.
minimize form
Accumulation clauses can be followed by `into var' to
cause the data to be collected into variable var (which is
automatically let-bound during the loop) rather than an
unnamed temporary variable. Also, into accumulations do
not automatically imply a return value. The loop must use some
explicit mechanism, such as finally return, to return
the accumulated result.
It is legal for several accumulation clauses of the same type to accumulate into the same place. From Steele:
(loop for name in '(fred sue alice joe june)
for kids in '((bob ken) () () (kris sunshine) ())
collect name
append kids)
=> (fred bob ken sue alice joe kris sunshine june)
This section describes the remaining loop clauses.
with var = value
(loop with x = 17 do ...) (let ((x 17)) (loop do ...)) (loop for x = 17 then x do ...)
Naturally, the variable var might be used for some purpose in the rest of the loop. For example:
(loop for x in my-list with res = nil do (push x res)
finally return res)
This loop inserts the elements of my-list at the front of
a new list being accumulated in res, then returns the
list res at the end of the loop. The effect is similar
to that of a collect clause, but the list gets reversed
by virtue of the fact that elements are being pushed onto the
front of res rather than the end.
If you omit the = term, the variable is initialized to
nil. (Thus the `= nil' in the above example is
unnecessary.)
Bindings made by with are sequential by default, as if
by let*. Just like for clauses, with clauses
can be linked with and to cause the bindings to be made by
let instead.
if condition clause
do, return, if, or unless clause.
Several clauses may be linked by separating them with and.
These clauses may be followed by else and a clause or clauses
to execute if the condition was false. The whole construct may
optionally be followed by the word end (which may be used to
disambiguate an else or and in a nested if).
The actual non-nil value of the condition form is available
by the name it in the "then" part. For example:
(setq funny-numbers '(6 13 -1))
=> (6 13 -1)
(loop for x below 10
if (oddp x)
collect x into odds
and if (memq x funny-numbers) return (cdr it) end
else
collect x into evens
finally return (vector odds evens))
=> [(1 3 5 7 9) (0 2 4 6 8)]
(setq funny-numbers '(6 7 13 -1))
=> (6 7 13 -1)
(loop <same thing again>)
=> (13 -1)
Note the use of and to put two clauses into the "then"
part, one of which is itself an if clause. Note also that
end, while normally optional, was necessary here to make
it clear that the else refers to the outermost if
clause. In the first case, the loop returns a vector of lists
of the odd and even values of x. In the second case, the
odd number 7 is one of the funny-numbers so the loop
returns early; the actual returned value is based on the result
of the memq call.
when condition clause
if.
unless condition clause
unless clause is just like if except that the
sense of the condition is reversed.
named name
nil to the implicit
block surrounding the loop. The name is the symbol to be
used as the block name.
initially [do] forms...
for or with have been bound to their
initial values). initially clauses can appear anywhere;
if there are several, they are executed in the order they appear
in the loop. The keyword do is optional.
finally [do] forms...
for or while).
initially and finally clauses may appear anywhere
in the loop construct, but they are executed (in the specified
order) at the beginning or end, respectively, of the loop.
finally return form
collect or return, the loop will simply
return nil.) Variables bound by for, with,
or into will still contain their final values when form
is executed.
do forms...
do may be followed by any number of Lisp expressions
which are executed as an implicit progn in the body of the
loop. Many of the examples in this section illustrate the use of
do.
return form
loop
form. The finally clauses, if any, are not executed.
Of course, return is generally used inside an if or
unless, as its use in a top-level loop clause would mean
the loop would never get to "loop" more than once.
The clause `return form' is equivalent to
`do (return form)' (or return-from if the loop
was named). The return clause is implemented a bit more
efficiently, though.
While there is no high-level way to add user extensions to loop
(comparable to defsetf for setf, say), this package
does offer two properties called cl-loop-handler and
cl-loop-for-handler which are functions to be called when
a given symbol is encountered as a top-level loop clause or
for clause, respectively. Consult the source code in
file `cl-macs.el' for details.
This package's loop macro is compatible with that of Common
Lisp, except that a few features are not implemented: loop-finish
and data-type specifiers. Naturally, the for clauses which
iterate over keymaps, overlays, intervals, frames, windows, and
buffers are Emacs-specific extensions.
Common Lisp functions can return zero or more results. Emacs Lisp
functions, by contrast, always return exactly one result. This
package makes no attempt to emulate Common Lisp multiple return
values; Emacs versions of Common Lisp functions that return more
than one value either return just the first value (as in
compiler-macroexpand) or return a list of values (as in
get-setf-method). This package does define placeholders
for the Common Lisp functions that work with multiple values, but
in Emacs Lisp these functions simply operate on lists instead.
The values form, for example, is a synonym for list
in Emacs.
Special Form: multiple-value-bind (var...) values-form forms...
This form evaluates values-form, which must return a list of
values. It then binds the vars to these respective values,
as if by let, and then executes the body forms.
If there are more vars than values, the extra vars
are bound to nil. If there are fewer vars than
values, the excess values are ignored.
Special Form: multiple-value-setq (var...) form
This form evaluates form, which must return a list of values.
It then sets the vars to these respective values, as if by
setq. Extra vars or values are treated the same as
in multiple-value-bind.
The older Quiroz package attempted a more faithful (but still
imperfect) emulation of Common Lisp multiple values. The old
method "usually" simulated true multiple values quite well,
but under certain circumstances would leave spurious return
values in memory where a later, unrelated multiple-value-bind
form would see them.
Since a perfect emulation is not feasible in Emacs Lisp, this package opts to keep it as simple and predictable as possible.
This package implements the various Common Lisp features of
defmacro, such as destructuring, &environment,
and &body. Top-level &whole is not implemented
for defmacro due to technical difficulties.
See section Argument Lists.
Destructuring is made available to the user by way of the following macro:
Special Form: destructuring-bind arglist expr forms...
This macro expands to code which executes forms, with
the variables in arglist bound to the list of values
returned by expr. The arglist can include all
the features allowed for defmacro argument lists,
including destructuring. (The &environment keyword
is not allowed.) The macro expansion will signal an error
if expr returns a list of the wrong number of arguments
or with incorrect keyword arguments.
This package also includes the Common Lisp define-compiler-macro
facility, which allows you to define compile-time expansions and
optimizations for your functions.
Special Form: define-compiler-macro name arglist forms...
This form is similar to defmacro, except that it only expands
calls to name at compile-time; calls processed by the Lisp
interpreter are not expanded, nor are they expanded by the
macroexpand function.
The argument list may begin with a &whole keyword and a
variable. This variable is bound to the macro-call form itself,
i.e., to a list of the form `(name args...)'.
If the macro expander returns this form unchanged, then the
compiler treats it as a normal function call. This allows
compiler macros to work as optimizers for special cases of a
function, leaving complicated cases alone.
For example, here is a simplified version of a definition that appears as a standard part of this package:
(define-compiler-macro member* (&whole form a list &rest keys)
(if (and (null keys)
(eq (car-safe a) 'quote)
(not (floatp-safe (cadr a))))
(list 'memq a list)
form))
This definition causes (member* a list) to change
to a call to the faster memq in the common case where a
is a non-floating-point constant; if a is anything else, or
if there are any keyword arguments in the call, then the original
member* call is left intact. (The actual compiler macro
for member* optimizes a number of other cases, including
common :test predicates.)
Function: compiler-macroexpand form
This function is analogous to macroexpand, except that it
expands compiler macros rather than regular macros. It returns
form unchanged if it is not a call to a function for which
a compiler macro has been defined, or if that compiler macro
decided to punt by returning its &whole argument. Like
macroexpand, it expands repeatedly until it reaches a form
for which no further expansion is possible.
See section Macro Bindings, for descriptions of the macrolet
and symbol-macrolet forms for making "local" macro
definitions.
Common Lisp includes a complex and powerful "declaration"
mechanism that allows you to give the compiler special hints
about the types of data that will be stored in particular variables,
and about the ways those variables and functions will be used. This
package defines versions of all the Common Lisp declaration forms:
declare, locally, proclaim, declaim,
and the.
Most of the Common Lisp declarations are not currently useful in
Emacs Lisp, as the byte-code system provides little opportunity
to benefit from type information, and special declarations
are redundant in a fully dynamically-scoped Lisp. A few
declarations are meaningful when the optimizing Emacs 19 byte
compiler is being used, however. Under the earlier non-optimizing
compiler, these declarations will effectively be ignored.
This function records a "global" declaration specified by
decl-spec. Since proclaim is a function, decl-spec
is evaluated and thus should normally be quoted.
Special Form: declaim decl-specs...
This macro is like proclaim, except that it takes any number
of decl-spec arguments, and the arguments are unevaluated and
unquoted. The declaim macro also puts an (eval-when
(compile load eval) ...) around the declarations so that they will
be registered at compile-time as well as at run-time. (This is vital,
since normally the declarations are meant to influence the way the
compiler treats the rest of the file that contains the declaim
form.)
Special Form: declare decl-specs...
This macro is used to make declarations within functions and other
code. Common Lisp allows declarations in various locations, generally
at the beginning of any of the many "implicit progns"
throughout Lisp syntax, such as function bodies, let bodies,
etc. Currently the only declaration understood by declare
is special.
Special Form: locally declarations... forms...
In this package, locally is no different from progn.
Type information provided by the is ignored in this package;
in other words, (the type form) is equivalent
to form. Future versions of the optimizing byte-compiler may
make use of this information.
For example, mapcar can map over both lists and arrays. It is
hard for the compiler to expand mapcar into an in-line loop
unless it knows whether the sequence will be a list or an array ahead
of time. With (mapcar 'car (the vector foo)), a future
compiler would have enough information to expand the loop in-line.
For now, Emacs Lisp will treat the above code as exactly equivalent
to (mapcar 'car foo).
Each decl-spec in a proclaim, declaim, or
declare should be a list beginning with a symbol that says
what kind of declaration it is. This package currently understands
special, inline, notinline, optimize,
and warn declarations. (The warn declaration is an
extension of standard Common Lisp.) Other Common Lisp declarations,
such as type and ftype, are silently ignored.
special
special declarations are only advisory. They
simply tell the optimizing byte compiler that the specified
variables are intentionally being referred to without being
bound in the body of the function. The compiler normally emits
warnings for such references, since they could be typographical
errors for references to local variables.
The declaration (declare (special var1 var2)) is
equivalent to (defvar var1) (defvar var2) in the
optimizing compiler, or to nothing at all in older compilers (which
do not warn for non-local references).
In top-level contexts, it is generally better to write
(defvar var) than (declaim (special var)),
since defvar makes your intentions clearer. But the older
byte compilers can not handle defvars appearing inside of
functions, while (declare (special var)) takes care
to work correctly with all compilers.
inline
inline decl-spec lists one or more functions
whose bodies should be expanded "in-line" into calling functions
whenever the compiler is able to arrange for it. For example,
the Common Lisp function cadr is declared