\input texinfo    @c -*-texinfo-*-
@setfilename ../info/cl
@settitle Common Lisp Extensions

@copying
This file documents the GNU Emacs Common Lisp emulation package.

Copyright @copyright{} 1993, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
Free Software Foundation, Inc.

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with the Front-Cover texts being ``A GNU
Manual'', and with the Back-Cover Texts as in (a) below.  A copy of the
license is included in the section entitled ``GNU Free Documentation
License'' in the Emacs manual.

(a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify
this GNU Manual, like GNU software.  Copies published by the Free
Software Foundation raise funds for GNU development.''

This document is part of a collection distributed under the GNU Free
Documentation License.  If you want to distribute this document
separately from the collection, you can do so by adding a copy of the
license to the document, as described in section 6 of the license.
@end quotation
@end copying

@dircategory Emacs
@direntry
* CL: (cl).		Partial Common Lisp support for Emacs Lisp.
@end direntry

@finalout

@titlepage
@sp 6
@center @titlefont{Common Lisp Extensions}
@sp 4
@center For GNU Emacs Lisp
@sp 1
@center Version 2.02
@sp 5
@center Dave Gillespie
@center daveg@@synaptics.com
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@node Top, Overview, (dir), (dir)
@chapter Introduction

@noindent
This document describes a set of Emacs Lisp facilities borrowed from
Common Lisp.  All the facilities are described here in detail.  While
this document does not assume any prior knowledge of Common Lisp, it
does assume a basic familiarity with Emacs Lisp.

@menu
* Overview::             Installation, usage, etc.
* Program Structure::    Arglists, `eval-when', `defalias'
* Predicates::           `typep' and `equalp'
* Control Structure::    `setf', `do', `loop', etc.
* Macros::               Destructuring, `define-compiler-macro'
* Declarations::         `proclaim', `declare', etc.
* Symbols::              Property lists, `gensym'
* Numbers::              Predicates, functions, random numbers
* Sequences::            Mapping, functions, searching, sorting
* Lists::                `caddr', `sublis', `member*', `assoc*', etc.
* Structures::           `defstruct'
* Assertions::           `check-type', `assert', `ignore-errors'.

* Efficiency Concerns::         Hints and techniques
* Common Lisp Compatibility::   All known differences with Steele
* Old CL Compatibility::        All known differences with old cl.el
* Porting Common Lisp::         Hints for porting Common Lisp code

* GNU Free Documentation License:: The license for this documentation.
* Function Index::
* Variable Index::
@end menu

@node Overview, Program Structure, Top, Top
@ifnottex
@chapter Overview
@end ifnottex

@noindent
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 @dfn{CL} package adds a number of Common Lisp functions and
control structures to Emacs Lisp.  While not a 100% complete
implementation of Common Lisp, @dfn{CL} adds enough functionality
to make Emacs Lisp programming significantly more convenient.

@strong{Please note:} the @dfn{CL} functions are not standard parts of
the Emacs Lisp name space, so it is legitimate for users to define
them with other, conflicting meanings.  To avoid conflicting with
those user activities, we have a policy that packages installed in
Emacs must not load @dfn{CL} at run time.  (It is ok for them to load
@dfn{CL} at compile time only, with @code{eval-when-compile}, and use
the macros it provides.)  If you are writing packages that you plan to
distribute and invite widespread use for, you might want to observe
the same rule.

Some Common Lisp features have been omitted from this package
for various reasons:

@itemize @bullet
@item
Some features are too complex or bulky relative to their benefit
to Emacs Lisp programmers.  CLOS and Common Lisp streams are fine
examples of this group.

@item
Other features cannot be implemented without modification to the
Emacs Lisp interpreter itself, such as multiple return values,
lexical scoping, case-insensitive symbols, and complex numbers.
The @dfn{CL} package generally makes no attempt to emulate these
features.

@item
Some features conflict with existing things in Emacs Lisp.  For
example, Emacs' @code{assoc} function is incompatible with the
Common Lisp @code{assoc}.  In such cases, this package usually
adds the suffix @samp{*} to the function name of the Common
Lisp version of the function (e.g., @code{assoc*}).
@end itemize

The package described here was written by Dave Gillespie,
@file{daveg@@synaptics.com}.  It is a total rewrite of the original
1986 @file{cl.el} package by Cesar Quiroz.  Most features of 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.

@menu
* Usage::                How to use the CL package
* Organization::         The package's five component files
* Installation::         Compiling and installing CL
* Naming Conventions::   Notes on CL function names
@end menu

@node Usage, Organization, Overview, Overview
@section Usage

@noindent
Lisp code that uses features from the @dfn{CL} package should
include at the beginning:

@example
(require 'cl)
@end example

@noindent
If you want to ensure that the new (Gillespie) version of @dfn{CL}
is the one that is present, add an additional @code{(require 'cl-19)}
call:

@example
(require 'cl)
(require 'cl-19)
@end example

@noindent
The second call will fail (with ``@file{cl-19.el} not found'') if
the old @file{cl.el} package was in use.

It is safe to arrange to load @dfn{CL} at all times, e.g.,
in your @file{.emacs} file.  But it's a good idea, for portability,
to @code{(require 'cl)} in your code even if you do this.

@node Organization, Installation, Usage, Overview
@section Organization

@noindent
The Common Lisp package is organized into four files:

@table @file
@item cl.el
This is the ``main'' file, which contains basic functions
and information about the package.  This file is relatively
compact---about 700 lines.

@item cl-extra.el
This file contains the larger, more complex or unusual functions.
It is kept separate so that packages which only want to use Common
Lisp fundamentals like the @code{cadr} function won't need to pay
the overhead of loading the more advanced functions.

@item cl-seq.el
This file contains most of the advanced functions for operating
on sequences or lists, such as @code{delete-if} and @code{assoc*}.

@item cl-macs.el
This file contains the features of the packages which are macros
instead of functions.  Macros expand when the caller is compiled,
not when it is run, so the macros generally only need to be
present when the byte-compiler is running (or when the macros are
used in uncompiled code such as a @file{.emacs} file).  Most of
the macros of this package are isolated in @file{cl-macs.el} so
that they won't take up memory unless you are compiling.
@end table

The file @file{cl.el} includes all necessary @code{autoload}
commands for the functions and macros in the other three files.
All you have to do is @code{(require 'cl)}, and @file{cl.el}
will take care of pulling in the other files when they are
needed.

There is another file, @file{cl-compat.el}, which defines some
routines from the older @file{cl.el} package that are no longer
present in the new package.  This includes internal routines
like @code{setelt} and @code{zip-lists}, deprecated features
like @code{defkeyword}, and an emulation of the old-style
multiple-values feature.  @xref{Old CL Compatibility}.

@node Installation, Naming Conventions, Organization, Overview
@section Installation

@noindent
Installation of the @dfn{CL} package is simple:  Just put the
byte-compiled files @file{cl.elc}, @file{cl-extra.elc},
@file{cl-seq.elc}, @file{cl-macs.elc}, and @file{cl-compat.elc}
into a directory on your @code{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 @file{lisp/}
directory, replacing the original @file{cl.el} file there.  Or,
you could put them into a directory that comes before @file{lisp/}
on your @code{load-path} so that the old @file{cl.el} is
effectively hidden.

Also, format the @file{cl.texinfo} file and put the resulting
Info files in the @file{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
@code{load-path} and @code{Info-directory-list}.
Add the directory to the front of the list so the old @dfn{CL}
package and its documentation are hidden.

@node Naming Conventions,  , Installation, Overview
@section Naming Conventions

@noindent
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 @samp{*} has been appended to the Common Lisp name to obtain
the Emacs name:

@example
defun*        defsubst*     defmacro*     function*
member*       assoc*        rassoc*       get*
remove*       delete*       mapcar*       sort*
floor*        ceiling*      truncate*     round*
mod*          rem*          random*
@end example

Internal function and variable names in the package are prefixed
by @code{cl-}.  Here is a complete list of functions @emph{not}
prefixed by @code{cl-} which were not taken from Common Lisp:

@example
floatp-safe   lexical-let   lexical-let*
callf         callf2        letf          letf*
defsubst*
@end example

The following simple functions and macros are defined in @file{cl.el};
they do not cause other components like @file{cl-extra} to be loaded.

@example
floatp-safe   endp
evenp         oddp          plusp         minusp
caaar .. cddddr
list*         ldiff         rest          first .. tenth
copy-list     subst         mapcar* [2]
adjoin [3]    acons         pairlis       pop [4]
push [4]      pushnew [3,4] incf [4]      decf [4]
proclaim      declaim
@end example

@noindent
[2] Only for one sequence argument or two list arguments.

@noindent
[3] Only if @code{:test} is @code{eq}, @code{equal}, or unspecified,
and @code{:key} is not used.

@noindent
[4] Only when @var{place} is a plain variable name.

@iftex
@chapno=4
@end iftex

@node Program Structure, Predicates, Overview, Top
@chapter Program Structure

@noindent
This section describes features of the @dfn{CL} package which have to
do with programs as a whole: advanced argument lists for functions,
and the @code{eval-when} construct.

@menu
* Argument Lists::       `&key', `&aux', `defun*', `defmacro*'.
* Time of Evaluation::   The `eval-when' construct.
@end menu

@iftex
@secno=1
@end iftex

@node Argument Lists, Time of Evaluation, Program Structure, Program Structure
@section Argument Lists

@noindent
Emacs Lisp's notation for argument lists of functions is a subset of
the Common Lisp notation.  As well as the familiar @code{&optional}
and @code{&rest} markers, Common Lisp allows you to specify default
values for optional arguments, and it provides the additional markers
@code{&key} and @code{&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.

@defspec defun* name arglist body...
This form is identical to the regular @code{defun} form, except
that @var{arglist} is allowed to be a full Common Lisp argument
list.  Also, the function body is enclosed in an implicit block
called @var{name}; @pxref{Blocks and Exits}.
@end defspec

@defspec defsubst* name arglist body...
This is just like @code{defun*}, except that the function that
is defined is automatically proclaimed @code{inline}, i.e.,
calls to it may be expanded into in-line code by the byte compiler.
This is analogous to the @code{defsubst} form;
@code{defsubst*} uses a different method (compiler macros) which
works in all version of Emacs, and also generates somewhat more
efficient inline expansions.  In particular, @code{defsubst*}
arranges for the processing of keyword arguments, default values,
etc., to be done at compile-time whenever possible.
@end defspec

@defspec defmacro* name arglist body...
This is identical to the regular @code{defmacro} form,
except that @var{arglist} is allowed to be a full Common Lisp
argument list.  The @code{&environment} keyword is supported as
described in Steele.  The @code{&whole} keyword is supported only
within destructured lists (see below); top-level @code{&whole}
cannot be implemented with the current Emacs Lisp interpreter.
The macro expander body is enclosed in an implicit block called
@var{name}.
@end defspec

@defspec function* symbol-or-lambda
This is identical to the regular @code{function} form,
except that if the argument is a @code{lambda} form then that
form may use a full Common Lisp argument list.
@end defspec

Also, all forms (such as @code{defsetf} and @code{flet}) defined
in this package that include @var{arglist}s in their syntax allow
full Common Lisp argument lists.

Note that it is @emph{not} necessary to use @code{defun*} in
order to have access to most @dfn{CL} features in your function.
These features are always present; @code{defun*}'s only
difference from @code{defun} is its more flexible argument
lists and its implicit block.

The full form of a Common Lisp argument list is

@example
(@var{var}...
 &optional (@var{var} @var{initform} @var{svar})...
 &rest @var{var}
 &key ((@var{keyword} @var{var}) @var{initform} @var{svar})...
 &aux (@var{var} @var{initform})...)
@end example

Each of the five argument list sections is optional.  The @var{svar},
@var{initform}, and @var{keyword} parts are optional; if they are
omitted, then @samp{(@var{var})} may be written simply @samp{@var{var}}.

The first section consists of zero or more @dfn{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 @dfn{optional} arguments.  These
arguments may be specified in the function call; if they are not,
@var{initform} specifies the default value used for the argument.
(No @var{initform} means to use @code{nil} as the default.)  The
@var{initform} is evaluated with the bindings for the preceding
arguments already established; @code{(a &optional (b (1+ a)))}
matches one or two arguments, with the second argument defaulting
to one plus the first argument.  If the @var{svar} is specified,
it is an auxiliary variable which is bound to @code{t} if the optional
argument was specified, or to @code{nil} if the argument was omitted.
If you don't use an @var{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 @dfn{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 @code{&rest} is equivalent to that of Emacs Lisp.
Common Lisp accepts @code{&body} as a synonym for @code{&rest} in
macro contexts; this package accepts it all the time.

The fourth section consists of @dfn{keyword} arguments.  These
are optional arguments which are specified by name rather than
positionally in the argument list.  For example,

@example
(defun* foo (a &optional b &key c d (e 17)))
@end example

@noindent
defines a function which may be called with one, two, or more
arguments.  The first two arguments are bound to @code{a} and
@code{b} in the usual way.  The remaining arguments must be
pairs of the form @code{:c}, @code{:d}, or @code{:e} followed
by the value to be bound to the corresponding argument variable.
(Symbols whose names begin with a colon are called @dfn{keywords},
and they are self-quoting in the same way as @code{nil} and
@code{t}.)

For example, the call @code{(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 @code{b} as well, since @code{(foo 1 :c 2)} would bind
@code{b} to the keyword @code{:c}, then signal an error because
@code{2} is not a valid keyword.

If a @var{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 @var{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., @code{(foo 1 2 :c 3 :goober 4)}.  You can ask
Lisp to ignore unrecognized keywords, either by adding the
marker @code{&allow-other-keys} after the keyword section
of the argument list, or by specifying an @code{:allow-other-keys}
argument in the call whose value is non-@code{nil}.  If the
function uses both @code{&rest} and @code{&key} at the same time,
the ``rest'' argument is bound to the keyword list as it appears
in the call.  For example:

@smallexample
(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"))))
@end smallexample

@noindent
This function takes a @code{:need} keyword argument, but also
accepts other keyword arguments which are passed on to the
@code{member*} function.  @code{allow-other-keys} is used to
keep both @code{find-thing} and @code{member*} from complaining
about each others' keywords in the arguments.

The fifth section of the argument list consists of @dfn{auxiliary
variables}.  These are not really arguments at all, but simply
variables which are bound to @code{nil} or to the specified
@var{initforms} during execution of the function.  There is no
difference between the following two functions, except for a
matter of stylistic taste:

@example
(defun* foo (a b &aux (c (+ a b)) d)
  @var{body})

(defun* foo (a b)
  (let ((c (+ a b)) d)
    @var{body}))
@end example

Argument lists support @dfn{destructuring}.  In Common Lisp,
destructuring is only allowed with @code{defmacro}; this package
allows it with @code{defun*} and other argument lists as well.
In destructuring, any argument variable (@var{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:

@example
(defmacro* dolist ((var listform &optional resultform)
                   &rest body)
  ...)
@end example

This says that the first argument of @code{dolist} must be a list
of two or three items; if there are other arguments as well as this
list, they are stored in @code{body}.  All features allowed in
regular argument lists are allowed in these recursive argument lists.
In addition, the clause @samp{&whole @var{var}} is allowed at the
front of a recursive argument list.  It binds @var{var} to the
whole list being matched; thus @code{(&whole all a b)} matches
a list of two things, with @code{a} bound to the first thing,
@code{b} bound to the second thing, and @code{all} bound to the
list itself.  (Common Lisp allows @code{&whole} in top-level
@code{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 @code{(a b . c)} is functionally
equivalent to @code{(a b &rest c)}.

If the optimization quality @code{safety} is set to 0
(@pxref{Declarations}), error checking for wrong number of
arguments and invalid keyword arguments is disabled.  By default,
argument lists are rigorously checked.

@node Time of Evaluation,  , Argument Lists, Program Structure
@section Time of Evaluation

@noindent
Normally, the byte-compiler does not actually execute the forms in
a file it compiles.  For example, if a file contains @code{(setq foo t)},
the act of compiling it will not actually set @code{foo} to @code{t}.
This is true even if the @code{setq} was a top-level form (i.e., not
enclosed in a @code{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 @code{defmacro} forms
at compile-time so that later parts of the file can refer to the
macros that are defined.

@defspec eval-when (situations...) forms...
This form controls when the body @var{forms} are evaluated.
The @var{situations} list may contain any set of the symbols
@code{compile}, @code{load}, and @code{eval} (or their long-winded
ANSI equivalents, @code{:compile-toplevel}, @code{:load-toplevel},
and @code{:execute}).

The @code{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 @code{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 @code{progn}.

For compiled top-level @code{eval-when}s, the body @var{forms} are
executed at compile-time if @code{compile} is in the @var{situations}
list, and the @var{forms} are written out to the file (to be executed
at load-time) if @code{load} is in the @var{situations} list.

For non-compiled-top-level forms, only the @code{eval} situation is
relevant.  (This includes forms executed by the interpreter, forms
compiled with @code{byte-compile} rather than @code{byte-compile-file},
and non-top-level forms.)  The @code{eval-when} acts like a
@code{progn} if @code{eval} is specified, and like @code{nil}
(ignoring the body @var{forms}) if not.

The rules become more subtle when @code{eval-when}s are nested;
consult Steele (second edition) for the gruesome details (and
some gruesome examples).

Some simple examples:

@example
;; 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))
@end example

When @file{foo.el} is compiled, these variables will be set during
the compilation itself:

@example
foo1  foo3  foo5  foo7      ; `compile'
@end example

When @file{foo.elc} is loaded, these variables will be set:

@example
foo2  foo3  foo6  foo7      ; `load'
@end example

And if @file{foo.el} is loaded uncompiled, these variables will
be set:

@example
foo4  foo5  foo6  foo7      ; `eval'
@end example

If these seven @code{eval-when}s had been, say, inside a @code{defun},
then the first three would have been equivalent to @code{nil} and the
last four would have been equivalent to the corresponding @code{setq}s.

Note that @code{(eval-when (load eval) @dots{})} is equivalent
to @code{(progn @dots{})} in all contexts.  The compiler treats
certain top-level forms, like @code{defmacro} (sort-of) and
@code{require}, as if they were wrapped in @code{(eval-when
(compile load eval) @dots{})}.
@end defspec

Emacs includes two special forms related to @code{eval-when}.
One of these, @code{eval-when-compile}, is not quite equivalent to
any @code{eval-when} construct and is described below.

The other form, @code{(eval-and-compile @dots{})}, is exactly
equivalent to @samp{(eval-when (compile load eval) @dots{})} and
so is not itself defined by this package.

@defspec eval-when-compile forms...
The @var{forms} are evaluated at compile-time; at execution time,
this form acts like a quoted constant of the resulting value.  Used
at top-level, @code{eval-when-compile} is just like @samp{eval-when
(compile eval)}.  In other contexts, @code{eval-when-compile}
allows code to be evaluated once at compile-time for efficiency
or other reasons.

This form is similar to the @samp{#.} syntax of true Common Lisp.
@end defspec

@defspec load-time-value form
The @var{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 @samp{#,} syntax that was similar to
this, but ANSI Common Lisp replaced it with @code{load-time-value}
and gave it more well-defined semantics.

In a compiled file, @code{load-time-value} arranges for @var{form}
to be evaluated when the @file{.elc} file is loaded and then used
as if it were a quoted constant.  In code compiled by
@code{byte-compile} rather than @code{byte-compile-file}, the
effect is identical to @code{eval-when-compile}.  In uncompiled
code, both @code{eval-when-compile} and @code{load-time-value}
act exactly like @code{progn}.

@example
(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))))
@end example

@noindent
Byte-compiled, the above defun will result in the following code
(or its compiled equivalent, of course) in the @file{.elc} file:

@example
(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--))
@end example
@end defspec

@node Predicates, Control Structure, Program Structure, Top
@chapter Predicates

@noindent
This section describes functions for testing whether various
facts are true or false.

@menu
* Type Predicates::      `typep', `deftype', and `coerce'
* Equality Predicates::  `equalp'
@end menu

@node Type Predicates, Equality Predicates, Predicates, Predicates
@section Type Predicates

@noindent
The @dfn{CL} package defines a version of the Common Lisp @code{typep}
predicate.

@defun typep object type
Check if @var{object} is of type @var{type}, where @var{type} is a
(quoted) type name of the sort used by Common Lisp.  For example,
@code{(typep foo 'integer)} is equivalent to @code{(integerp foo)}.
@end defun

The @var{type} argument to the above function is either a symbol
or a list beginning with a symbol.

@itemize @bullet
@item
If the type name is a symbol, Emacs appends @samp{-p} to the
symbol name to form the name of a predicate function for testing
the type.  (Built-in predicates whose names end in @samp{p} rather
than @samp{-p} are used when appropriate.)

@item
The type symbol @code{t} stands for the union of all types.
@code{(typep @var{object} t)} is always true.  Likewise, the
type symbol @code{nil} stands for nothing at all, and
@code{(typep @var{object} nil)} is always false.

@item
The type symbol @code{null} represents the symbol @code{nil}.
Thus @code{(typep @var{object} 'null)} is equivalent to
@code{(null @var{object})}.

@item
The type symbol @code{atom} represents all objects that are not cons
cells. Thus @code{(typep @var{object} 'atom)} is equivalent to
@code{(atom @var{object})}.

@item
The type symbol @code{real} is a synonym for @code{number}, and
@code{fixnum} is a synonym for @code{integer}.

@item
The type symbols @code{character} and @code{string-char} match
integers in the range from 0 to 255.

@item
The type symbol @code{float} uses the @code{floatp-safe} predicate
defined by this package rather than @code{floatp}, so it will work
correctly even in Emacs versions without floating-point support.

@item
The type list @code{(integer @var{low} @var{high})} represents all
integers between @var{low} and @var{high}, inclusive.  Either bound
may be a list of a single integer to specify an exclusive limit,
or a @code{*} to specify no limit.  The type @code{(integer * *)}
is thus equivalent to @code{integer}.

@item
Likewise, lists beginning with @code{float}, @code{real}, or
@code{number} represent numbers of that type falling in a particular
range.

@item
Lists beginning with @code{and}, @code{or}, and @code{not} form
combinations of types.  For example, @code{(or integer (float 0 *))}
represents all objects that are integers or non-negative floats.

@item
Lists beginning with @code{member} or @code{member*} represent
objects @code{eql} to any of the following values.  For example,
@code{(member 1 2 3 4)} is equivalent to @code{(integer 1 4)},
and @code{(member nil)} is equivalent to @code{null}.

@item
Lists of the form @code{(satisfies @var{predicate})} represent
all objects for which @var{predicate} returns true when called
with that object as an argument.
@end itemize

The following function and macro (not technically predicates) are
related to @code{typep}.

@defun coerce object type
This function attempts to convert @var{object} to the specified
@var{type}.  If @var{object} is already of that type as determined by
@code{typep}, it is simply returned.  Otherwise, certain types of
conversions will be made:  If @var{type} is any sequence type
(@code{string}, @code{list}, etc.) then @var{object} will be
converted to that type if possible.  If @var{type} is
@code{character}, then strings of length one and symbols with
one-character names can be coerced.  If @var{type} is @code{float},
then integers can be coerced in versions of Emacs that support
floats.  In all other circumstances, @code{coerce} signals an
error.
@end defun

@defspec deftype name arglist forms...
This macro defines a new type called @var{name}.  It is similar
to @code{defmacro} in many ways; when @var{name} is encountered
as a type name, the body @var{forms} are evaluated and should
return a type specifier that is equivalent to the type.  The
@var{arglist} is a Common Lisp argument list of the sort accepted
by @code{defmacro*}.  The type specifier @samp{(@var{name} @var{args}...)}
is expanded by calling the expander with those arguments; the type
symbol @samp{@var{name}} is expanded by calling the expander with
no arguments.  The @var{arglist} is processed the same as for
@code{defmacro*} except that optional arguments without explicit
defaults use @code{*} instead of @code{nil} as the ``default''
default.  Some examples:

@example
(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)  @equiv{}  (integer 0 255)
(unsigned-byte)  @equiv{}  (integer 0 *)
unsigned-byte  @equiv{}  (integer 0 *)
@end example

@noindent
The last example shows how the Common Lisp @code{unsigned-byte}
type specifier could be implemented if desired; this package does
not implement @code{unsigned-byte} by default.
@end defspec

The @code{typecase} and @code{check-type} macros also use type
names.  @xref{Conditionals}.  @xref{Assertions}.  The @code{map},
@code{concatenate}, and @code{merge} functions take type-name
arguments to specify the type of sequence to return.  @xref{Sequences}.

@node Equality Predicates,  , Type Predicates, Predicates
@section Equality Predicates

@noindent
This package defines the Common Lisp predicate @code{equalp}.

@defun equalp a b
This function is a more flexible version of @code{equal}.  In
particular, it compares strings case-insensitively, and it compares
numbers without regard to type (so that @code{(equalp 3 3.0)} is
true).  Vectors and conses are compared recursively.  All other
objects are compared as if by @code{equal}.

This function differs from Common Lisp @code{equalp} in several
respects.  First, Common Lisp's @code{equalp} also compares
@emph{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 @code{equalp} also will
not compare strings against vectors of integers.
@end defun

Also note that the Common Lisp functions @code{member} and @code{assoc}
use @code{eql} to compare elements, whereas Emacs Lisp follows the
MacLisp tradition and uses @code{equal} for these two functions.
In Emacs, use @code{member*} and @code{assoc*} to get functions
which use @code{eql} for comparisons.

@node Control Structure, Macros, Predicates, Top
@chapter Control Structure

@noindent
The features described in the following sections implement
various advanced control structures, including the powerful
@code{setf} facility and a number of looping and conditional
constructs.

@menu
* Assignment::             The `psetq' form
* Generalized Variables::  `setf', `incf', `push', etc.
* Variable Bindings::      `progv', `lexical-let', `flet', `macrolet'
* Conditionals::           `case', `typecase'
* Blocks and Exits::       `block', `return', `return-from'
* Iteration::              `do', `dotimes', `dolist', `do-symbols'
* Loop Facility::          The Common Lisp `loop' macro
* Multiple Values::        `values', `multiple-value-bind', etc.
@end menu

@node Assignment, Generalized Variables, Control Structure, Control Structure
@section Assignment

@noindent
The @code{psetq} form is just like @code{setq}, except that multiple
assignments are done in parallel rather than sequentially.

@defspec psetq [symbol form]@dots{}
This special form (actually a macro) is used to assign to several
variables simultaneously.  Given only one @var{symbol} and @var{form},
it has the same effect as @code{setq}.  Given several @var{symbol}
and @var{form} pairs, it evaluates all the @var{form}s in advance
and then stores the corresponding variables afterwards.

@example
(setq x 2 y 3)
(setq x (+ x y)  y (* x y))
x
     @result{} 5
y                     ; @r{@code{y} was computed after @code{x} was set.}
     @result{} 15
(setq x 2 y 3)
(psetq x (+ x y)  y (* x y))
x
     @result{} 5
y                     ; @r{@code{y} was computed before @code{x} was set.}
     @result{} 6
@end example

The simplest use of @code{psetq} is @code{(psetq x y y x)}, which
exchanges the values of two variables.  (The @code{rotatef} form
provides an even more convenient way to swap two variables;
@pxref{Modify Macros}.)

@code{psetq} always returns @code{nil}.
@end defspec

@node Generalized Variables, Variable Bindings, Assignment, Control Structure
@section Generalized Variables

@noindent
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 @code{setf} form is like @code{setq}, except that it accepts
arbitrary place forms on the left side rather than just
symbols.  For example, @code{(setf (car a) b)} sets the car of
@code{a} to @code{b}, doing the same operation as @code{(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 @samp{x = a[i]} gets an element from an array
and @samp{a[i] = x} stores an element using the same notation.
Just as certain forms like @code{a[i]} can be lvalues in C, there
is a set of forms that can be generalized variables in Lisp.

@menu
* Basic Setf::         `setf' and place forms
* Modify Macros::      `incf', `push', `rotatef', `letf', `callf', etc.
* Customizing Setf::   `define-modify-macro', `defsetf', `define-setf-method'
@end menu

@node Basic Setf, Modify Macros, Generalized Variables, Generalized Variables
@subsection Basic Setf

@noindent
The @code{setf} macro is the most basic way to operate on generalized
variables.

@defspec setf [place form]@dots{}
This macro evaluates @var{form} and stores it in @var{place}, which
must be a valid generalized variable form.  If there are several
@var{place} and @var{form} pairs, the assignments are done sequentially
just as with @code{setq}.  @code{setf} returns the value of the last
@var{form}.

The following Lisp forms will work as generalized variables, and
so may appear in the @var{place} argument of @code{setf}:

@itemize @bullet
@item
A symbol naming a variable.  In other words, @code{(setf x y)} is
exactly equivalent to @code{(setq x y)}, and @code{setq} itself is
strictly speaking redundant now that @code{setf} exists.  Many
programmers continue to prefer @code{setq} for setting simple
variables, though, purely for stylistic or historical reasons.
The macro @code{(setf x y)} actually expands to @code{(setq x y)},
so there is no performance penalty for using it in compiled code.

@item
A call to any of the following Lisp functions:

@smallexample
car                 cdr                 caar .. cddddr
nth                 rest                first .. tenth
aref                elt                 nthcdr
symbol-function     symbol-value        symbol-plist
get                 get*                getf
gethash             subseq
@end smallexample

@noindent
Note that for @code{nthcdr} and @code{getf}, the list argument
of the function must itself be a valid @var{place} form.  For
example, @code{(setf (nthcdr 0 foo) 7)} will set @code{foo} itself
to 7.  Note that @code{push} and @code{pop} on an @code{nthcdr}
place can be used to insert or delete at any position in a list.
The use of @code{nthcdr} as a @var{place} form is an extension
to standard Common Lisp.

@item
The following Emacs-specific functions are also @code{setf}-able.

@smallexample
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
@end smallexample

Most of these have directly corresponding ``set'' functions, like
@code{use-local-map} for @code{current-local-map}, or @code{goto-char}
for @code{point}.  A few, like @code{point-min}, expand to longer
sequences of code when they are @code{setf}'d (@code{(narrow-to-region
x (point-max))} in this case).

@item
A call of the form @code{(substring @var{subplace} @var{n} [@var{m}])},
where @var{subplace} is itself a valid 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:

@example
(setq a (list "hello" "world"))
     @result{} ("hello" "world")
(cadr a)
     @result{} "world"
(substring (cadr a) 2 4)
     @result{} "rl"
(setf (substring (cadr a) 2 4) "o")
     @result{} "o"
(cadr a)
     @result{} "wood"
a
     @result{} ("hello" "wood")
@end example

The generalized variable @code{buffer-substring}, listed above,
also works in this way by replacing a portion of the current buffer.

@item
A call of the form @code{(apply '@var{func} @dots{})} or
@code{(apply (function @var{func}) @dots{})}, where @var{func}
is a @code{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
@code{define-setf-method} or the long form of @code{defsetf}.

@item
A macro call, in which case the macro is expanded and @code{setf}
is applied to the resulting form.

@item
Any form for which a @code{defsetf} or @code{define-setf-method}
has been made.
@end itemize

Using any forms other than these in the @var{place} argument to
@code{setf} will signal an error.

The @code{setf} macro takes care to evaluate all subforms in
the proper left-to-right order; for example,

@example
(setf (aref vec (incf i)) i)
@end example

@noindent
looks like it will evaluate @code{(incf i)} exactly once, before the
following access to @code{i}; the @code{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 @code{aref}.
(In this case, @code{aset} would be used and no such steps would
be necessary since @code{aset} takes its arguments in a convenient
order.)

However, if the @var{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

@example
(defmacro wrong-order (x y) (list 'aref y x))
@end example

@noindent
the form @code{(setf (wrong-order @var{a} @var{b}) 17)} will
evaluate @var{b} first, then @var{a}, just as in an actual call
to @code{wrong-order}.
@end defspec

@node Modify Macros, Customizing Setf, Basic Setf, Generalized Variables
@subsection Modify Macros

@noindent
This package defines a number of other macros besides @code{setf}
that operate on generalized variables.  Many are interesting and
useful even when the @var{place} is just a variable name.

@defspec psetf [place form]@dots{}
This macro is to @code{setf} what @code{psetq} is to @code{setq}:
When several @var{place}s and @var{form}s 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).
@end defspec

@defspec incf place &optional x
This macro increments the number stored in @var{place} by one, or
by @var{x} if specified.  The incremented value is returned.  For
example, @code{(incf i)} is equivalent to @code{(setq i (1+ i))}, and
@code{(incf (car x) 2)} is equivalent to @code{(setcar x (+ (car x) 2))}.

Once again, care is taken to preserve the ``apparent'' order of
evaluation.  For example,

@example
(incf (aref vec (incf i)))
@end example

@noindent
appears to increment @code{i} once, then increment the element of
@code{vec} addressed by @code{i}; this is indeed exactly what it
does, which means the above form is @emph{not} equivalent to the
``obvious'' expansion,

@example
(setf (aref vec (incf i)) (1+ (aref vec (incf i))))   ; Wrong!
@end example

@noindent
but rather to something more like

@example
(let ((temp (incf i)))
  (setf (aref vec temp) (1+ (aref vec temp))))
@end example

@noindent
Again, all of this is taken care of automatically by @code{incf} and
the other generalized-variable macros.

As a more Emacs-specific example of @code{incf}, the expression
@code{(incf (point) @var{n})} is essentially equivalent to
@code{(forward-char @var{n})}.
@end defspec

@defspec decf place &optional x
This macro decrements the number stored in @var{place} by one, or
by @var{x} if specified.
@end defspec

@defspec pop place
This macro removes and returns the first element of the list stored
in @var{place}.  It is analogous to @code{(prog1 (car @var{place})
(setf @var{place} (cdr @var{place})))}, except that it takes care
to evaluate all subforms only once.
@end defspec

@defspec push x place
This macro inserts @var{x} at the front of the list stored in
@var{place}.  It is analogous to @code{(setf @var{place} (cons
@var{x} @var{place}))}, except for evaluation of the subforms.
@end defspec

@defspec pushnew x place @t{&key :test :test-not :key}
This macro inserts @var{x} at the front of the list stored in
@var{place}, but only if @var{x} was not @code{eql} to any
existing element of the list.  The optional keyword arguments
are interpreted in the same way as for @code{adjoin}.
@xref{Lists as Sets}.
@end defspec

@defspec shiftf place@dots{} newvalue
This macro shifts the @var{place}s left by one, shifting in the
value of @var{newvalue} (which may be any Lisp expression, not just
a generalized variable), and returning the value shifted out of
the first @var{place}.  Thus, @code{(shiftf @var{a} @var{b} @var{c}
@var{d})} is equivalent to

@example
(prog1
    @var{a}
  (psetf @var{a} @var{b}
         @var{b} @var{c}
         @var{c} @var{d}))
@end example

@noindent
except that the subforms of @var{a}, @var{b}, and @var{c} are actually
evaluated only once each and in the apparent order.
@end defspec

@defspec rotatef place@dots{}
This macro rotates the @var{place}s left by one in circular fashion.
Thus, @code{(rotatef @var{a} @var{b} @var{c} @var{d})} is equivalent to

@example
(psetf @var{a} @var{b}
       @var{b} @var{c}
       @var{c} @var{d}
       @var{d} @var{a})
@end example

@noindent
except for the evaluation of subforms.  @code{rotatef} always
returns @code{nil}.  Note that @code{(rotatef @var{a} @var{b})}
conveniently exchanges @var{a} and @var{b}.
@end defspec

The following macros were invented for this package; they have no
analogues in Common Lisp.

@defspec letf (bindings@dots{}) forms@dots{}
This macro is analogous to @code{let}, but for generalized variables
rather than just symbols.  Each @var{binding} should be of the form
@code{(@var{place} @var{value})}; the original contents of the
@var{place}s are saved, the @var{value}s are stored in them, and
then the body @var{form}s are executed.  Afterwards, the @var{places}
are set back to their original saved contents.  This cleanup happens
even if the @var{form}s exit irregularly due to a @code{throw} or an
error.

For example,

@example
(letf (((point) (point-min))
       (a 17))
  ...)
@end example

@noindent
moves ``point'' in the current buffer to the beginning of the buffer,
and also binds @code{a} to 17 (as if by a normal @code{let}, since
@code{a} is just a regular variable).  After the body exits, @code{a}
is set back to its original value and point is moved back to its
original position.

Note that @code{letf} on @code{(point)} is not quite like a
@code{save-excursion}, as the latter effectively saves a marker
which tracks insertions and deletions in the buffer.  Actually,
a @code{letf} of @code{(point-marker)} is much closer to this
behavior.  (@code{point} and @code{point-marker} are equivalent
as @code{setf} places; each will accept either an integer or a
marker as the stored value.)

Since generalized variables look like lists, @code{let}'s shorthand
of using @samp{foo} for @samp{(foo nil)} as a @var{binding} would
be ambiguous in @code{letf} and is not allowed.

However, a @var{binding} specifier may be a one-element list
@samp{(@var{place})}, which is similar to @samp{(@var{place}
@var{place})}.  In other words, the @var{place} is not disturbed
on entry to the body, and the only effect of the @code{letf} is
to restore the original value of @var{place} afterwards.  (The
redundant access-and-store suggested by the @code{(@var{place}
@var{place})} example does not actually occur.)

In most cases, the @var{place} must have a well-defined value on
entry to the @code{letf} form.  The only exceptions are plain
variables and calls to @code{symbol-value} and @code{symbol-function}.
If the symbol is not bound on entry, it is simply made unbound by
@code{makunbound} or @code{fmakunbound} on exit.
@end defspec

@defspec letf* (bindings@dots{}) forms@dots{}
This macro is to @code{letf} what @code{let*} is to @code{let}:
It does the bindings in sequential rather than parallel order.
@end defspec

@defspec callf @var{function} @var{place} @var{args}@dots{}
This is the ``generic'' modify macro.  It calls @var{function},
which should be an unquoted function name, macro name, or lambda.
It passes @var{place} and @var{args} as arguments, and assigns the
result back to @var{place}.  For example, @code{(incf @var{place}
@var{n})} is the same as @code{(callf + @var{place} @var{n})}.
Some more examples:

@example
(callf abs my-number)
(callf concat (buffer-name) "<" (int-to-string n) ">")
(callf union happy-people (list joe bob) :test 'same-person)
@end example

@xref{Customizing Setf}, for @code{define-modify-macro}, a way
to create even more concise notations for modify macros.  Note
again that @code{callf} is an extension to standard Common Lisp.
@end defspec

@defspec callf2 @var{function} @var{arg1} @var{place} @var{args}@dots{}
This macro is like @code{callf}, except that @var{place} is
the @emph{second} argument of @var{function} rather than the
first.  For example, @code{(push @var{x} @var{place})} is
equivalent to @code{(callf2 cons @var{x} @var{place})}.
@end defspec

The @code{callf} and @code{callf2} macros serve as building
blocks for other macros like @code{incf}, @code{pushnew}, and
@code{define-modify-macro}.  The @code{letf} and @code{letf*}
macros are used in the processing of symbol macros;
@pxref{Macro Bindings}.

@node Customizing Setf,  , Modify Macros, Generalized Variables
@subsection Customizing Setf

@noindent
Common Lisp defines three macros, @code{define-modify-macro},
@code{defsetf}, and @code{define-setf-method}, that allow the
user to extend generalized variables in various ways.

@defspec define-modify-macro name arglist function [doc-string]
This macro defines a ``read-modify-write'' macro similar to
@code{incf} and @code{decf}.  The macro @var{name} is defined
to take a @var{place} argument followed by additional arguments
described by @var{arglist}.  The call

@example
(@var{name} @var{place} @var{args}...)
@end example

@noindent
will be expanded to

@example
(callf @var{func} @var{place} @var{args}...)
@end example

@noindent
which in turn is roughly equivalent to

@example
(setf @var{place} (@var{func} @var{place} @var{args}...))
@end example

For example:

@example
(define-modify-macro incf (&optional (n 1)) +)
(define-modify-macro concatf (&rest args) concat)
@end example

Note that @code{&key} is not allowed in @var{arglist}, but
@code{&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 @code{define-modify-macro}.  For example,
@code{push} takes its arguments in the wrong order, and @code{pop}
is completely irregular.  You can define these macros ``by hand''
using @code{get-setf-method}, or consult the source file
@file{cl-macs.el} to see how to use the internal @code{setf}
building blocks.
@end defspec

@defspec defsetf access-fn update-fn
This is the simpler of two @code{defsetf} forms.  Where
@var{access-fn} is the name of a function which accesses a place,
this declares @var{update-fn} to be the corresponding store
function.  From now on,

@example
(setf (@var{access-fn} @var{arg1} @var{arg2} @var{arg3}) @var{value})
@end example

@noindent
will be expanded to

@example
(@var{update-fn} @var{arg1} @var{arg2} @var{arg3} @var{value})
@end example

@noindent
The @var{update-fn} is required to be either a true function, or
a macro which evaluates its arguments in a function-like way.  Also,
the @var{update-fn} is expected to return @var{value} as its result.
Otherwise, the above expansion would not obey the rules for the way
@code{setf} is supposed to behave.

As a special (non-Common-Lisp) extension, a third argument of @code{t}
to @code{defsetf} says that the @code{update-fn}'s return value is
not suitable, so that the above @code{setf} should be expanded to
something more like

@example
(let ((temp @var{value}))
  (@var{update-fn} @var{arg1} @var{arg2} @var{arg3} temp)
  temp)
@end example

Some examples of the use of @code{defsetf}, drawn from the standard
suite of setf methods, are:

@example
(defsetf car setcar)
(defsetf symbol-value set)
(defsetf buffer-name rename-buffer t)
@end example
@end defspec

@defspec defsetf access-fn arglist (store-var) forms@dots{}
This is the second, more complex, form of @code{defsetf}.  It is
rather like @code{defmacro} except for the additional @var{store-var}
argument.  The @var{forms} should return a Lisp form which stores
the value of @var{store-var} into the generalized variable formed
by a call to @var{access-fn} with arguments described by @var{arglist}.
The @var{forms} may begin with a string which documents the @code{setf}
method (analogous to the doc string that appears at the front of a
function).

For example, the simple form of @code{defsetf} is shorthand for

@example
(defsetf @var{access-fn} (&rest args) (store)
  (append '(@var{update-fn}) args (list store)))
@end example

The Lisp form that is returned can access the arguments from
@var{arglist} and @var{store-var} in an unrestricted fashion;
macros like @code{setf} and @code{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:

@example
(defsetf nth (n x) (store)
  (list 'setcar (list 'nthcdr n x) store))
@end example
@end defspec

@defspec define-setf-method access-fn arglist forms@dots{}
This is the most general way to create new place forms.  When
a @code{setf} to @var{access-fn} with arguments described by
@var{arglist} is expanded, the @var{forms} are evaluated and
must return a list of five items:

@enumerate
@item
A list of @dfn{temporary variables}.

@item
A list of @dfn{value forms} corresponding to the temporary variables
above.  The temporary variables will be bound to these value forms
as the first step of any operation on the generalized variable.

@item
A list of exactly one @dfn{store variable} (generally obtained
from a call to @code{gensym}).

@item
A Lisp form which stores the contents of the store variable into
the generalized variable, assuming the temporaries have been
bound as described above.

@item
A Lisp form which accesses the contents of the generalized variable,
assuming the temporaries have been bound.
@end enumerate

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 @var{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
@code{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 @code{gensym}.  Macros like @code{setf} and @code{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.
@end defspec

@defun get-setf-method place &optional env
This function returns the setf-method for @var{place}, by
invoking the definition previously recorded by @code{defsetf}
or @code{define-setf-method}.  The result is a list of five
values as described above.  You can use this function to build
your own @code{incf}-like modify macros.  (Actually, it is
better to use the internal functions @code{cl-setf-do-modify}
and @code{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 @code{incf} function for a simple example.)

The argument @var{env} specifies the ``environment'' to be
passed on to @code{macroexpand} if @code{get-setf-method} should
need to expand a macro in @var{place}.  It should come from
an @code{&environment} argument to the macro or setf-method
that called @code{get-setf-method}.

See also the source code for the setf-methods for @code{apply}
and @code{substring}, each of which works by calling
@code{get-setf-method} on a simpler case, then massaging
the result in various ways.
@end defun

Modern Common Lisp defines a second, independent way to specify
the @code{setf} behavior of a function, namely ``@code{setf}
functions'' whose names are lists @code{(setf @var{name})}
rather than symbols.  For example, @code{(defun (setf foo) @dots{})}
defines the function that is used when @code{setf} is applied to
@code{foo}.  This package does not currently support @code{setf}
functions.  In particular, it is a compile-time error to use
@code{setf} on a form which has not already been @code{defsetf}'d
or otherwise declared; in newer Common Lisps, this would not be
an error since the function @code{(setf @var{func})} might be
defined later.

@iftex
@secno=4
@end iftex

@node Variable Bindings, Conditionals, Generalized Variables, Control Structure
@section Variable Bindings

@noindent
These Lisp forms make bindings to variables and function names,
analogous to Lisp's built-in @code{let} form.

@xref{Modify Macros}, for the @code{letf} and @code{letf*} forms which
are also related to variable bindings.

@menu
* Dynamic Bindings::     The `progv' form
* Lexical Bindings::     `lexical-let' and lexical closures
* Function Bindings::    `flet' and `labels'
* Macro Bindings::       `macrolet' and `symbol-macrolet'
@end menu

@node Dynamic Bindings, Lexical Bindings, Variable Bindings, Variable Bindings
@subsection Dynamic Bindings

@noindent
The standard @code{let} form binds variables whose names are known
at compile-time.  The @code{progv} form provides an easy way to
bind variables whose names are computed at run-time.

@defspec progv symbols values forms@dots{}
This form establishes @code{let}-style variable bindings on a
set of variables computed at run-time.  The expressions
@var{symbols} and @var{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 @var{form}s.
If @var{values} is shorter than @var{symbols}, the last few symbols
are made unbound (as if by @code{makunbound}) inside the body.
If @var{symbols} is shorter than @var{values}, the excess values
are ignored.
@end defspec

@node Lexical Bindings, Function Bindings, Dynamic Bindings, Variable Bindings
@subsection Lexical Bindings

@noindent
The @dfn{CL} package defines the following macro which
more closely follows the Common Lisp @code{let} form:

@defspec lexical-let (bindings@dots{}) forms@dots{}
This form is exactly like @code{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 @code{lexical-let} (after macro expansion)
may refer to the bound variables.

@example
(setq a 5)
(defun foo (b) (+ a b))
(let ((a 2)) (foo a))
     @result{} 4
(lexical-let ((a 2)) (foo a))
     @result{} 7
@end example

@noindent
In this example, a regular @code{let} binding of @code{a} actually
makes a temporary change to the global variable @code{a}, so @code{foo}
is able to see the binding of @code{a} to 2.  But @code{lexical-let}
actually creates a distinct local variable @code{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 @dfn{closures}.
A closure is a function object that refers to an outside lexical
variable.  For example:

@example
(defun make-adder (n)
  (lexical-let ((n n))
    (function (lambda (m) (+ n m)))))
(setq add17 (make-adder 17))
(funcall add17 4)
     @result{} 21
@end example

@noindent
The call @code{(make-adder 17)} returns a function object which adds
17 to its argument.  If @code{let} had been used instead of
@code{lexical-let}, the function object would have referred to the
global @code{n}, which would have been bound to 17 only during the
call to @code{make-adder} itself.

@example
(defun make-counter ()
  (lexical-let ((n 0))
    (function* (lambda (&optional (m 1)) (incf n m)))))
(setq count-1 (make-counter))
(funcall count-1 3)
     @result{} 3
(funcall count-1 14)
     @result{} 17
(setq count-2 (make-counter))
(funcall count-2 5)
     @result{} 5
(funcall count-1 2)
     @result{} 19
(funcall count-2)
     @result{} 6
@end example

@noindent
Here we see that each call to @code{make-counter} creates a distinct
local variable @code{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,
@code{count-2} refers to a function object which refers to an
instance of the variable @code{n}; this is the only reference
to that variable, so after @code{(setq count-2 nil)} the garbage
collector would be able to delete this instance of @code{n}.
Of course, if a @code{lexical-let} does not actually create any
closures, then the lexical variables are free as soon as the
@code{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 @code{lexical-let}
closures:

@example
(defun add-to-list (x list)
  (mapcar (lambda (y) (+ x y))) list)
(add-to-list 7 '(1 2 5))
     @result{} (8 9 12)
@end example

@noindent
Since this lambda is only used while @code{x} is still bound,
it is not necessary to make a true closure out of it.

You can use @code{defun} or @code{flet} inside a @code{lexical-let}
to create a named closure.  If several closures are created in the
body of a single @code{lexical-let}, they all close over the same
instance of the lexical variable.

The @code{lexical-let} form is an extension to Common Lisp.  In
true Common Lisp, all bindings are lexical unless declared otherwise.
@end defspec

@defspec lexical-let* (bindings@dots{}) forms@dots{}
This form is just like @code{lexical-let}, except that the bindings
are made sequentially in the manner of @code{let*}.
@end defspec

@node Function Bindings, Macro Bindings, Lexical Bindings, Variable Bindings
@subsection Function Bindings

@noindent
These forms make @code{let}-like bindings to functions instead
of variables.

@defspec flet (bindings@dots{}) forms@dots{}
This form establishes @code{let}-style bindings on the function
cells of symbols rather than on the value cells.  Each @var{binding}
must be a list of the form @samp{(@var{name} @var{arglist}
@var{forms}@dots{})}, which defines a function exactly as if
it were a @code{defun*} form.  The function @var{name} is defined
accordingly for the duration of the body of the @code{flet}; then
the old function definition, or lack thereof, is restored.

While @code{flet} in Common Lisp establishes a lexical binding of
@var{name}, Emacs Lisp @code{flet} makes a dynamic binding.  The
result is that @code{flet} affects indirect calls to a function as
well as calls directly inside the @code{flet} form itself.

You can use @code{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 @code{flet}.  For
example,

@example
(flet ((message (&rest args) (push args saved-msgs)))
  (do-something))
@end example

This code attempts to replace the built-in function @code{message}
with a function that simply saves the messages in a list rather
than displaying them.  The original definition of @code{message}
will be restored after @code{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 @code{message} function.

Functions defined by @code{flet} may use the full Common Lisp
argument notation supported by @code{defun*}; also, the function
body is enclosed in an implicit block as if by @code{defun*}.
@xref{Program Structure}.
@end defspec

@defspec labels (bindings@dots{}) forms@dots{}
The @code{labels} form is like @code{flet}, except that it
makes lexical bindings of the function names rather than
dynamic bindings.  (In true Common Lisp, both @code{flet} and
@code{labels} make lexical bindings of slightly different sorts;
since Emacs Lisp is dynamically bound by default, it seemed
more appropriate for @code{flet} also to use dynamic binding.
The @code{labels} form, with its lexical binding, is fully
compatible with Common Lisp.)

Lexical scoping means that all references to the named
functions must appear physically within the body of the
@code{labels} form.  References may appear both in the body
@var{forms} of @code{labels} itself, and in the bodies of
the functions themselves.  Thus, @code{labels} can define
local recursive functions, or mutually-recursive sets of
functions.

A ``reference'' to a function name is either a call to that
function, or a use of its name quoted by @code{quote} or
@code{function} to be passed on to, say, @code{mapcar}.
@end defspec

@node Macro Bindings,  , Function Bindings, Variable Bindings
@subsection Macro Bindings

@noindent
These forms create local macros and ``symbol macros.''

@defspec macrolet (bindings@dots{}) forms@dots{}
This form is analogous to @code{flet}, but for macros instead of
functions.  Each @var{binding} is a list of the same form as the
arguments to @code{defmacro*} (i.e., a macro name, argument list,
and macro-expander forms).  The macro is defined accordingly for
use within the body of the @code{macrolet}.

Because of the nature of macros, @code{macrolet} is lexically
scoped even in Emacs Lisp:  The @code{macrolet} binding will
affect only calls that appear physically within the body
@var{forms}, possibly after expansion of other macros in the
body.
@end defspec

@defspec symbol-macrolet (bindings@dots{}) forms@dots{}
This form creates @dfn{symbol macros}, which are macros that look
like variable references rather than function calls.  Each
@var{binding} is a list @samp{(@var{var} @var{expansion})};
any reference to @var{var} within the body @var{forms} is
replaced by @var{expansion}.

@example
(setq bar '(5 . 9))
(symbol-macrolet ((foo (car bar)))
  (incf foo))
bar
     @result{} (6 . 9)
@end example

A @code{setq} of a symbol macro is treated the same as a @code{setf}.
I.e., @code{(setq foo 4)} in the above would be equivalent to
@code{(setf foo 4)}, which in turn expands to @code{(setf (car bar) 4)}.

Likewise, a @code{let} or @code{let*} binding a symbol macro is
treated like a @code{letf} or @code{letf*}.  This differs from true
Common Lisp, where the rules of lexical scoping cause a @code{let}
binding to shadow a @code{symbol-macrolet} binding.  In this package,
only @code{lexical-let} and @code{lexical-let*} will shadow a symbol
macro.

There is no analogue of @code{defmacro} for symbol macros; all symbol
macros are local.  A typical use of @code{symbol-macrolet} is in the
expansion of another macro:

@example
(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
     @result{} (2 3 4 5)
@end example

@noindent
In this example, the @code{my-dolist} macro is similar to @code{dolist}
(@pxref{Iteration}) except that the variable @code{x} becomes a true
reference onto the elements of the list.  The @code{my-dolist} call
shown here expands to

@example
(loop for G1234 on mylist do
      (symbol-macrolet ((x (car G1234)))
        (incf x)))
@end example

@noindent
which in turn expands to

@example
(loop for G1234 on mylist do (incf (car G1234)))
@end example

@xref{Loop Facility}, for a description of the @code{loop} macro.
This package defines a nonstandard @code{in-ref} loop clause that
works much like @code{my-dolist}.
@end defspec

@node Conditionals, Blocks and Exits, Variable Bindings, Control Structure
@section Conditionals

@noindent
These conditional forms augment Emacs Lisp's simple @code{if},
@code{and}, @code{or}, and @code{cond} forms.

@defspec case keyform clause@dots{}
This macro evaluates @var{keyform}, then compares it with the key
values listed in the various @var{clause}s.  Whichever clause matches
the key is executed; comparison is done by @code{eql}.  If no clause
matches, the @code{case} form returns @code{nil}.  The clauses are
of the form

@example
(@var{keylist} @var{body-forms}@dots{})
@end example

@noindent
where @var{keylist} is a list of key values.  If there is exactly
one value, and it is not a cons cell or the symbol @code{nil} or
@code{t}, then it can be used by itself as a @var{keylist} without
being enclosed in a list.  All key values in the @code{case} form
must be distinct.  The final clauses may use @code{t} in place of
a @var{keylist} to indicate a default clause that should be taken
if none of the other clauses match.  (The symbol @code{otherwise}
is also recognized in place of @code{t}.  To make a clause that
matches the actual symbol @code{t}, @code{nil}, or @code{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 @samp{a}, a @samp{b},
a @key{RET} or @kbd{C-j}, or anything else.

@example
(case (read-char)
  (?a (do-a-thing))
  (?b (do-b-thing))
  ((?\r ?\n) (do-ret-thing))
  (t (do-other-thing)))
@end example
@end defspec

@defspec ecase keyform clause@dots{}
This macro is just like @code{case}, except that if the key does
not match any of the clauses, an error is signaled rather than
simply returning @code{nil}.
@end defspec

@defspec typecase keyform clause@dots{}
This macro is a version of @code{case} that checks for types
rather than values.  Each @var{clause} is of the form
@samp{(@var{type} @var{body}...)}.  @xref{Type Predicates},
for a description of type specifiers.  For example,

@example
(typecase x
  (integer (munch-integer x))
  (float (munch-float x))
  (string (munch-integer (string-to-int x)))
  (t (munch-anything x)))
@end example

The type specifier @code{t} matches any type of object; the word
@code{otherwise} is also allowed.  To make one clause match any of
several types, use an @code{(or ...)} type specifier.
@end defspec

@defspec etypecase keyform clause@dots{}
This macro is just like @code{typecase}, except that if the key does
not match any of the clauses, an error is signaled rather than
simply returning @code{nil}.
@end defspec

@node Blocks and Exits, Iteration, Conditionals, Control Structure
@section Blocks and Exits

@noindent
Common Lisp @dfn{blocks} provide a non-local exit mechanism very
similar to @code{catch} and @code{throw}, but lexically rather than
dynamically scoped.  This package actually implements @code{block}
in terms of @code{catch}; however, the lexical scoping allows the
optimizing byte-compiler to omit the costly @code{catch} step if the
body of the block does not actually @code{return-from} the block.

@defspec block name forms@dots{}
The @var{forms} are evaluated as if by a @code{progn}.  However,
if any of the @var{forms} execute @code{(return-from @var{name})},
they will jump out and return directly from the @code{block} form.
The @code{block} returns the result of the last @var{form} unless
a @code{return-from} occurs.

The @code{block}/@code{return-from} mechanism is quite similar to
the @code{catch}/@code{throw} mechanism.  The main differences are
that block @var{name}s 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 @code{catch}/@code{throw}
are dynamically scoped.  This means that functions called from the
body of a @code{catch} can also @code{throw} to the @code{catch},
but the @code{return-from} referring to a block name must appear
physically within the @var{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 @code{lambda}s in the body.  Block
names and @code{catch} names form independent name-spaces.

In true Common Lisp, @code{defun} and @code{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 @code{defun*} and @code{defmacro*}
forms which do create the implicit block.

The Common Lisp looping constructs defined by this package,
such as @code{loop} and @code{dolist}, also create implicit blocks
just as in Common Lisp.

Because they are implemented in terms of Emacs Lisp @code{catch}
and @code{throw}, blocks have the same overhead as actual
@code{catch} constructs (roughly two function calls).  However,
the optimizing byte compiler will optimize away the @code{catch}
if the block does
not in fact contain any @code{return} or @code{return-from} calls
that jump to it.  This means that @code{do} loops and @code{defun*}
functions which don't use @code{return} don't pay the overhead to
support it.
@end defspec

@defspec return-from name [result]
This macro returns from the block named @var{name}, which must be
an (unevaluated) symbol.  If a @var{result} form is specified, it
is evaluated to produce the result returned from the @code{block}.
Otherwise, @code{nil} is returned.
@end defspec

@defspec return [result]
This macro is exactly like @code{(return-from nil @var{result})}.
Common Lisp loops like @code{do} and @code{dolist} implicitly enclose
themselves in @code{nil} blocks.
@end defspec

@node Iteration, Loop Facility, Blocks and Exits, Control Structure
@section Iteration

@noindent
The macros described here provide more sophisticated, high-level
looping constructs to complement Emacs Lisp's basic @code{while}
loop.

@defspec loop forms@dots{}
The @dfn{CL} package supports both the simple, old-style meaning of
@code{loop} and the extremely powerful and flexible feature known as
the @dfn{Loop Facility} or @dfn{Loop Macro}.  This more advanced
facility is discussed in the following section; @pxref{Loop Facility}.
The simple form of @code{loop} is described here.

If @code{loop} is followed by zero or more Lisp expressions,
then @code{(loop @var{exprs}@dots{})} simply creates an infinite
loop executing the expressions over and over.  The loop is
enclosed in an implicit @code{nil} block.  Thus,

@example
(loop (foo)  (if (no-more) (return 72))  (bar))
@end example

@noindent
is exactly equivalent to

@example
(block nil (while t (foo)  (if (no-more) (return 72))  (bar)))
@end example

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.)
@end defspec

@defspec do (spec@dots{}) (end-test [result@dots{}]) forms@dots{}
This macro creates a general iterative loop.  Each @var{spec} is
of the form

@example
(@var{var} [@var{init} [@var{step}]])
@end example

The loop works as follows:  First, each @var{var} is bound to the
associated @var{init} value as if by a @code{let} form.  Then, in
each iteration of the loop, the @var{end-test} is evaluated; if
true, the loop is finished.  Otherwise, the body @var{forms} are
evaluated, then each @var{var} is set to the associated @var{step}
expression (as if by a @code{psetq} form) and the next iteration
begins.  Once the @var{end-test} becomes true, the @var{result}
forms are evaluated (with the @var{var}s still bound to their
values) to produce the result returned by @code{do}.

The entire @code{do} loop is enclosed in an implicit @code{nil}
block, so that you can use @code{(return)} to break out of the
loop at any time.

If there are no @var{result} forms, the loop returns @code{nil}.
If a given @var{var} has no @var{step} form, it is bound to its
@var{init} value but not otherwise modified during the @code{do}
loop (unless the code explicitly modifies it); this case is just
a shorthand for putting a @code{(let ((@var{var} @var{init})) @dots{})}
around the loop.  If @var{init} is also omitted it defaults to
@code{nil}, and in this case a plain @samp{@var{var}} can be used
in place of @samp{(@var{var})}, again following the analogy with
@code{let}.

This example (from Steele) illustrates a loop which applies the
function @code{f} to successive pairs of values from the lists
@code{foo} and @code{bar}; it is equivalent to the call
@code{(mapcar* 'f foo bar)}.  Note that this loop has no body
@var{forms} at all, performing all its work as side effects of
the rest of the loop.

@example
(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)))
@end example
@end defspec

@defspec do* (spec@dots{}) (end-test [result@dots{}]) forms@dots{}
This is to @code{do} what @code{let*} is to @code{let}.  In
particular, the initial values are bound as if by @code{let*}
rather than @code{let}, and the steps are assigned as if by
@code{setq} rather than @code{psetq}.

Here is another way to write the above loop:

@example
(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))
@end example
@end defspec

@defspec dolist (var list [result]) forms@dots{}
This is a more specialized loop which iterates across the elements
of a list.  @var{list} should evaluate to a list; the body @var{forms}
are executed with @var{var} bound to each element of the list in
turn.  Finally, the @var{result} form (or @code{nil}) is evaluated
with @var{var} bound to @code{nil} to produce the result returned by
the loop.  Unlike with Emacs's built in @code{dolist}, the loop is
surrounded by an implicit @code{nil} block.
@end defspec

@defspec dotimes (var count [result]) forms@dots{}
This is a more specialized loop which iterates a specified number
of times.  The body is executed with @var{var} bound to the integers
from zero (inclusive) to @var{count} (exclusive), in turn.  Then
the @code{result} form is evaluated with @var{var} bound to the total
number of iterations that were done (i.e., @code{(max 0 @var{count})})
to get the return value for the loop form.  Unlike with Emacs's built in
@code{dolist}, the loop is surrounded by an implicit @code{nil} block.
@end defspec

@defspec do-symbols (var [obarray [result]]) forms@dots{}
This loop iterates over all interned symbols.  If @var{obarray}
is specified and is not @code{nil}, it loops over all symbols in
that obarray.  For each symbol, the body @var{forms} are evaluated
with @var{var} bound to that symbol.  The symbols are visited in
an unspecified order.  Afterward the @var{result} form, if any,
is evaluated (with @var{var} bound to @code{nil}) to get the return
value.  The loop is surrounded by an implicit @code{nil} block.
@end defspec

@defspec do-all-symbols (var [result]) forms@dots{}
This is identical to @code{do-symbols} except that the @var{obarray}
argument is omitted; it always iterates over the default obarray.
@end defspec

@xref{Mapping over Sequences}, for some more functions for
iterating over vectors or lists.

@node Loop Facility, Multiple Values, Iteration, Control Structure
@section Loop Facility

@noindent
A common complaint with Lisp's traditional looping constructs is
that they are either too simple and limited, such as Common Lisp's
@code{dotimes} or Emacs Lisp's @code{while}, or too unreadable and
obscure, like Common Lisp's @code{do} loop.

To remedy this, recent versions of Common Lisp have added a new
construct called the ``Loop Facility'' or ``@code{loop} macro,''
with an easy-to-use but very powerful and expressive syntax.

@menu
* Loop Basics::           `loop' macro, basic clause structure
* Loop Examples::         Working examples of `loop' macro
* For Clauses::           Clauses introduced by `for' or `as'
* Iteration Clauses::     `repeat', `while', `thereis', etc.
* Accumulation Clauses::  `collect', `sum', `maximize', etc.
* Other Clauses::         `with', `if', `initially', `finally'
@end menu

@node Loop Basics, Loop Examples, Loop Facility, Loop Facility
@subsection Loop Basics

@noindent
The @code{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 @code{loop} is a macro, all parsing of the loop language
takes place at byte-compile time; compiled @code{loop}s are just
as efficient as the equivalent @code{while} loops written longhand.

@defspec loop clauses@dots{}
A loop construct consists of a series of @var{clause}s, each
introduced by a symbol like @code{for} or @code{do}.  Clauses
are simply strung together in the argument list of @code{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:

@example
(loop @var{name-clause}
      @var{var-clauses}@dots{}
      @var{action-clauses}@dots{})
@end example

The @var{name-clause} optionally gives a name to the implicit
block that surrounds the loop.  By default, the implicit block
is named @code{nil}.  The @var{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
@var{action-clauses} are things to be done during the loop, such
as computing, collecting, and returning values.

The Emacs version of the @code{loop} macro is less restrictive about
the order of clauses, but things will behave most predictably if
you put the variable-binding clauses @code{with}, @code{for}, and
@code{repeat} before the action clauses.  As in Common Lisp,
@code{initially} and @code{finally} clauses can go anywhere.

Loops generally return @code{nil} by default, but you can cause
them to return a value by using an accumulation clause like
@code{collect}, an end-test clause like @code{always}, or an
explicit @code{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 @code{return} or @code{return-from} to
break out of the loop.)
@end defspec

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 @dfn{Common Lisp, the Language},
for additional discussion and examples of the @code{loop} macro.

@node Loop Examples, For Clauses, Loop Basics, Loop Facility
@subsection Loop Examples

@noindent
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 @code{loop}
language.

@example
(loop for buf in (buffer-list)
      collect (buffer-file-name buf))
@end example

@noindent
This loop iterates over all Emacs buffers, using the list
returned by @code{buffer-list}.  For each buffer @code{buf},
it calls @code{buffer-file-name} and collects the results into
a list, which is then returned from the @code{loop} construct.
The result is a list of the file names of all the buffers in
Emacs' memory.  The words @code{for}, @code{in}, and @code{collect}
are reserved words in the @code{loop} language.

@example
(loop repeat 20 do (insert "Yowsa\n"))
@end example

@noindent
This loop inserts the phrase ``Yowsa'' twenty times in the
current buffer.

@example
(loop until (eobp) do (munch-line) (forward-line 1))
@end example

@noindent
This loop calls @code{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.

@example
(loop do (munch-line) until (eobp) do (forward-line 1))
@end example

@noindent
This loop is similar to the above one, except that @code{munch-line}
is always called at least once.

@example
(loop for x from 1 to 100
      for y = (* x x)
      until (>= y 729)
      finally return (list x (= y 729)))
@end example

@noindent
This more complicated loop searches for a number @code{x} whose
square is 729.  For safety's sake it only examines @code{x}
values up to 100; dropping the phrase @samp{to 100} would
cause the loop to count upwards with no limit.  The second
@code{for} clause defines @code{y} to be the square of @code{x}
within the loop; the expression after the @code{=} sign is
reevaluated each time through the loop.  The @code{until}
clause gives a condition for terminating the loop, and the
@code{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
@code{for}s and an @code{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 @code{loop} constructs if you want nested loops.

@node For Clauses, Iteration Clauses, Loop Examples, Loop Facility
@subsection For Clauses

@noindent
Most loops are governed by one or more @code{for} clauses.
A @code{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 @code{as} is a synonym for the word @code{for}.  This
word is followed by a variable name, then a word like @code{from}
or @code{across} that describes the kind of iteration desired.
In Common Lisp, the phrase @code{being the} sometimes precedes
the type of iteration; in this package both @code{being} and
@code{the} are optional.  The word @code{each} is a synonym
for @code{the}, and the word that follows it may be singular
or plural:  @samp{for x being the elements of y} or
@samp{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 @code{let}:

@example
(setq i 'happy)
(loop for i from 1 to 10 do (do-something-with i))
i
     @result{} happy
@end example

@table @code
@item for @var{var} from @var{expr1} to @var{expr2} by @var{expr3}
This type of @code{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 (@var{expr3} must be positive), from @var{expr1}
to @var{expr2} inclusively.  If you omit the @code{from} term, the
loop counts from zero; if you omit the @code{to} term, the loop
counts forever without stopping (unless stopped by some other
loop clause, of course); if you omit the @code{by} term, the loop
counts in steps of one.

You can replace the word @code{from} with @code{upfrom} or
@code{downfrom} to indicate the direction of the loop.  Likewise,
you can replace @code{to} with @code{upto} or @code{downto}.
For example, @samp{for x from 5 downto 1} executes five times
with @code{x} taking on the integers from 5 down to 1 in turn.
Also, you can replace @code{to} with @code{below} or @code{above},
which are like @code{upto} and @code{downto} respectively except
that they are exclusive rather than inclusive limits:

@example
(loop for x to 10 collect x)
     @result{} (0 1 2 3 4 5 6 7 8 9 10)
(loop for x below 10 collect x)
     @result{} (0 1 2 3 4 5 6 7 8 9)
@end example

The @code{by} value is always positive, even for downward-counting
loops.  Some sort of @code{from} value is required for downward
loops; @samp{for x downto 5} is not a valid loop clause all by
itself.

@item for @var{var} in @var{list} by @var{function}
This clause iterates @var{var} over all the elements of @var{list},
in turn.  If you specify the @code{by} term, then @var{function}
is used to traverse the list instead of @code{cdr}; it must be a
function taking one argument.  For example:

@example
(loop for x in '(1 2 3 4 5 6) collect (* x x))
     @result{} (1 4 9 16 25 36)
(loop for x in '(1 2 3 4 5 6) by 'cddr collect (* x x))
     @result{} (1 9 25)
@end example

@item for @var{var} on @var{list} by @var{function}
This clause iterates @var{var} over all the cons cells of @var{list}.

@example
(loop for x on '(1 2 3 4) collect x)
     @result{} ((1 2 3 4) (2 3 4) (3 4) (4))
@end example

With @code{by}, there is no real reason that the @code{on} expression
must be a list.  For example:

@example
(loop for x on first-animal by 'next-animal collect x)
@end example

@noindent
where @code{(next-animal x)} takes an ``animal'' @var{x} and returns
the next in the (assumed) sequence of animals, or @code{nil} if
@var{x} was the last animal in the sequence.

@item for @var{var} in-ref @var{list} by @var{function}
This is like a regular @code{in} clause, but @var{var} becomes
a @code{setf}-able ``reference'' onto the elements of the list
rather than just a temporary variable.  For example,

@example
(loop for x in-ref my-list do (incf x))
@end example

@noindent
increments every element of @code{my-list} in place.  This clause
is an extension to standard Common Lisp.

@item for @var{var} across @var{array}
This clause iterates @var{var} over all the elements of @var{array},
which may be a vector or a string.

@example
(loop for x across "aeiou"
      do (use-vowel (char-to-string x)))
@end example

@item for @var{var} across-ref @var{array}
This clause iterates over an array, with @var{var} a @code{setf}-able
reference onto the elements; see @code{in-ref} above.

@item for @var{var} being the elements of @var{sequence}
This clause iterates over the elements of @var{sequence}, which may
be a list, vector, or string.  Since the type must be determined
at run-time, this is somewhat less efficient than @code{in} or
@code{across}.  The clause may be followed by the additional term
@samp{using (index @var{var2})} to cause @var{var2} to be bound to
the successive indices (starting at 0) of the elements.

This clause type is taken from older versions of the @code{loop} macro,
and is not present in modern Common Lisp.  The @samp{using (sequence ...)}
term of the older macros is not supported.

@item for @var{var} being the elements of-ref @var{sequence}
This clause iterates over a sequence, with @var{var} a @code{setf}-able
reference onto the elements; see @code{in-ref} above.

@item for @var{var} being the symbols [of @var{obarray}]
This clause iterates over symbols, either over all interned symbols
or over all symbols in @var{obarray}.  The loop is executed with
@var{var} bound to each symbol in turn.  The symbols are visited in
an unspecified order.

As an example,

@example
(loop for sym being the symbols
      when (fboundp sym)
      when (string-match "^map" (symbol-name sym))
      collect sym)
@end example

@noindent
returns a list of all the functions whose names begin with @samp{map}.

The Common Lisp words @code{external-symbols} and @code{present-symbols}
are also recognized but are equivalent to @code{symbols} in Emacs Lisp.

Due to a minor implementation restriction, it will not work to have
more than one @code{for} clause iterating over symbols, hash tables,
keymaps, overlays, or intervals in a given @code{loop}.  Fortunately,
it would rarely if ever be useful to do so.  It @emph{is} valid to mix
one of these types of clauses with other clauses like @code{for ... to}
or @code{while}.

@item for @var{var} being the hash-keys of @var{hash-table}
This clause iterates over the entries in @var{hash-table}.  For each
hash table entry, @var{var} is bound to the entry's key.  If you write
@samp{the hash-values} instead, @var{var} is bound to the values
of the entries.  The clause may be followed by the additional
term @samp{using (hash-values @var{var2})} (where @code{hash-values}
is the opposite word of the word following @code{the}) to cause
@var{var} and @var{var2} to be bound to the two parts of each
hash table entry.

@item for @var{var} being the key-codes of @var{keymap}
This clause iterates over the entries in @var{keymap}.
The iteration does not enter nested keymaps but does enter inherited
(parent) keymaps.
You can use @samp{the key-bindings} to access the commands bound to
the keys rather than the key codes, and you can add a @code{using}
clause to access both the codes and the bindings together.

@item for @var{var} being the key-seqs of @var{keymap}
This clause iterates over all key sequences defined by @var{keymap}
and its nested keymaps, where @var{var} takes on values which are
vectors.  The strings or vectors
are reused for each iteration, so you must copy them if you wish to keep
them permanently.  You can add a @samp{using (key-bindings ...)}
clause to get the command bindings as well.

@item for @var{var} being the overlays [of @var{buffer}] @dots{}
This clause iterates over the ``overlays'' of a buffer
(the clause @code{extents} is synonymous
with @code{overlays}).  If the @code{of} term is omitted, the current
buffer is used.
This clause also accepts optional @samp{from @var{pos}} and
@samp{to @var{pos}} terms, limiting the clause to overlays which
overlap the specified region.

@item for @var{var} being the intervals [of @var{buffer}] @dots{}
This clause iterates over all intervals of a buffer with constant
text properties.  The variable @var{var} will be bound to conses
of start and end positions, where one start position is always equal
to the previous end position.  The clause allows @code{of},
@code{from}, @code{to}, and @code{property} terms, where the latter
term restricts the search to just the specified property.  The
@code{of} term may specify either a buffer or a string.

@item for @var{var} being the frames
This clause iterates over all frames, i.e., X window system windows
open on Emacs files.  The
clause @code{screens} is a synonym for @code{frames}.  The frames
are visited in @code{next-frame} order starting from
@code{selected-frame}.

@item for @var{var} being the windows [of @var{frame}]
This clause iterates over the windows (in the Emacs sense) of
the current frame, or of the specified @var{frame}.

@item for @var{var} being the buffers
This clause iterates over all buffers in Emacs.  It is equivalent
to @samp{for @var{var} in (buffer-list)}.

@item for @var{var} = @var{expr1} then @var{expr2}
This clause does a general iteration.  The first time through
the loop, @var{var} will be bound to @var{expr1}.  On the second
and successive iterations it will be set by evaluating @var{expr2}
(which may refer to the old value of @var{var}).  For example,
these two loops are effectively the same:

@example
(loop for x on my-list by 'cddr do ...)
(loop for x = my-list then (cddr x) while x do ...)
@end example

Note that this type of @code{for} clause does not imply any sort
of terminating condition; the above example combines it with a
@code{while} clause to tell when to end the loop.

If you omit the @code{then} term, @var{expr1} is used both for
the initial setting and for successive settings:

@example
(loop for x = (random) when (> x 0) return x)
@end example

@noindent
This loop keeps taking random numbers from the @code{(random)}
function until it gets a positive one, which it then returns.
@end table

If you include several @code{for} clauses in a row, they are
treated sequentially (as if by @code{let*} and @code{setq}).
You can instead use the word @code{and} to link the clauses,
in which case they are processed in parallel (as if by @code{let}
and @code{psetq}).

@example
(loop for x below 5 for y = nil then x collect (list x y))
     @result{} ((0 nil) (1 1) (2 2) (3 3) (4 4))
(loop for x below 5 and y = nil then x collect (list x y))
     @result{} ((0 nil) (1 0) (2 1) (3 2) (4 3))
@end example

@noindent
In the first loop, @code{y} is set based on the value of @code{x}
that was just set by the previous clause; in the second loop,
@code{x} and @code{y} are set simultaneously so @code{y} is set
based on the value of @code{x} left over from the previous time
through the loop.

Another feature of the @code{loop} macro is @dfn{destructuring},
similar in concept to the destructuring provided by @code{defmacro}.
The @var{var} part of any @code{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.

@example
(loop for (x y) in '((2 3) (4 5) (6 7)) collect (+ x y))
     @result{} (5 9 13)
@end example

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 @code{nil}.
If @code{nil} is used as a variable name, the corresponding
values are ignored.  Destructuring may be nested, and dotted
lists of variables like @code{(x . y)} are allowed.

@node Iteration Clauses, Accumulation Clauses, For Clauses, Loop Facility
@subsection Iteration Clauses

@noindent
Aside from @code{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 @code{for} clauses.

@table @code
@item repeat @var{integer}
This clause simply counts up to the specified number using an
internal temporary variable.  The loops

@example
(loop repeat n do ...)
(loop for temp to n do ...)
@end example

@noindent
are identical except that the second one forces you to choose
a name for a variable you aren't actually going to use.

@item while @var{condition}
This clause stops the loop when the specified condition (any Lisp
expression) becomes @code{nil}.  For example, the following two
loops are equivalent, except for the implicit @code{nil} block
that surrounds the second one:

@example
(while @var{cond} @var{forms}@dots{})
(loop while @var{cond} do @var{forms}@dots{})
@end example

@item until @var{condition}
This clause stops the loop when the specified condition is true,
i.e., non-@code{nil}.

@item always @var{condition}
This clause stops the loop when the specified condition is @code{nil}.
Unlike @code{while}, it stops the loop using @code{return nil} so that
the @code{finally} clauses are not executed.  If all the conditions
were non-@code{nil}, the loop returns @code{t}:

@example
(if (loop for size in size-list always (> size 10))
    (some-big-sizes)
  (no-big-sizes))
@end example

@item never @var{condition}
This clause is like @code{always}, except that the loop returns
@code{t} if any conditions were false, or @code{nil} otherwise.

@item thereis @var{condition}
This clause stops the loop when the specified form is non-@code{nil};
in this case, it returns that non-@code{nil} value.  If all the
values were @code{nil}, the loop returns @code{nil}.
@end table

@node Accumulation Clauses, Other Clauses, Iteration Clauses, Loop Facility
@subsection Accumulation Clauses

@noindent
These clauses cause the loop to accumulate information about the
specified Lisp @var{form}.  The accumulated result is returned
from the loop unless overridden, say, by a @code{return} clause.

@table @code
@item collect @var{form}
This clause collects the values of @var{form} into a list.  Several
examples of @code{collect} appear elsewhere in this manual.

The word @code{collecting} is a synonym for @code{collect}, and
likewise for the other accumulation clauses.

@item append @var{form}
This clause collects lists of values into a result list using
@code{append}.

@item nconc @var{form}
This clause collects lists of values into a result list by
destructively modifying the lists rather than copying them.

@item concat @var{form}
This clause concatenates the values of the specified @var{form}
into a string.  (It and the following clause are extensions to
standard Common Lisp.)

@item vconcat @var{form}
This clause concatenates the values of the specified @var{form}
into a vector.

@item count @var{form}
This clause counts the number of times the specified @var{form}
evaluates to a non-@code{nil} value.

@item sum @var{form}
This clause accumulates the sum of the values of the specified
@var{form}, which must evaluate to a number.

@item maximize @var{form}
This clause accumulates the maximum value of the specified @var{form},
which must evaluate to a number.  The return value is undefined if
@code{maximize} is executed zero times.

@item minimize @var{form}
This clause accumulates the minimum value of the specified @var{form}.
@end table

Accumulation clauses can be followed by @samp{into @var{var}} to
cause the data to be collected into variable @var{var} (which is
automatically @code{let}-bound during the loop) rather than an
unnamed temporary variable.  Also, @code{into} accumulations do
not automatically imply a return value.  The loop must use some
explicit mechanism, such as @code{finally return}, to return
the accumulated result.

It is valid for several accumulation clauses of the same type to
accumulate into the same place.  From Steele:

@example
(loop for name in '(fred sue alice joe june)
      for kids in '((bob ken) () () (kris sunshine) ())
      collect name
      append kids)
     @result{} (fred bob ken sue alice joe kris sunshine june)
@end example

@node Other Clauses,  , Accumulation Clauses, Loop Facility
@subsection Other Clauses

@noindent
This section describes the remaining loop clauses.

@table @code
@item with @var{var} = @var{value}
This clause binds a variable to a value around the loop, but
otherwise leaves the variable alone during the loop.  The following
loops are basically equivalent:

@example
(loop with x = 17 do ...)
(let ((x 17)) (loop do ...))
(loop for x = 17 then x do ...)
@end example

Naturally, the variable @var{var} might be used for some purpose
in the rest of the loop.  For example:

@example
(loop for x in my-list  with res = nil  do (push x res)
      finally return res)
@end example

This loop inserts the elements of @code{my-list} at the front of
a new list being accumulated in @code{res}, then returns the
list @code{res} at the end of the loop.  The effect is similar
to that of a @code{collect} clause, but the list gets reversed
by virtue of the fact that elements are being pushed onto the
front of @code{res} rather than the end.

If you omit the @code{=} term, the variable is initialized to
@code{nil}.  (Thus the @samp{= nil} in the above example is
unnecessary.)

Bindings made by @code{with} are sequential by default, as if
by @code{let*}.  Just like @code{for} clauses, @code{with} clauses
can be linked with @code{and} to cause the bindings to be made by
@code{let} instead.

@item if @var{condition} @var{clause}
This clause executes the following loop clause only if the specified
condition is true.  The following @var{clause} should be an accumulation,
@code{do}, @code{return}, @code{if}, or @code{unless} clause.
Several clauses may be linked by separating them with @code{and}.
These clauses may be followed by @code{else} and a clause or clauses
to execute if the condition was false.  The whole construct may
optionally be followed by the word @code{end} (which may be used to
disambiguate an @code{else} or @code{and} in a nested @code{if}).

The actual non-@code{nil} value of the condition form is available
by the name @code{it} in the ``then'' part.  For example:

@example
(setq funny-numbers '(6 13 -1))
     @result{} (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))
     @result{} [(1 3 5 7 9) (0 2 4 6 8)]
(setq funny-numbers '(6 7 13 -1))
     @result{} (6 7 13 -1)
(loop <@r{same thing again}>)
     @result{} (13 -1)
@end example

Note the use of @code{and} to put two clauses into the ``then''
part, one of which is itself an @code{if} clause.  Note also that
@code{end}, while normally optional, was necessary here to make
it clear that the @code{else} refers to the outermost @code{if}
clause.  In the first case, the loop returns a vector of lists
of the odd and even values of @var{x}.  In the second case, the
odd number 7 is one of the @code{funny-numbers} so the loop
returns early; the actual returned value is based on the result
of the @code{memq} call.

@item when @var{condition} @var{clause}
This clause is just a synonym for @code{if}.

@item unless @var{condition} @var{clause}
The @code{unless} clause is just like @code{if} except that the
sense of the condition is reversed.

@item named @var{name}
This clause gives a name other than @code{nil} to the implicit
block surrounding the loop.  The @var{name} is the symbol to be
used as the block name.

@item initially [do] @var{forms}...
This keyword introduces one or more Lisp forms which will be
executed before the loop itself begins (but after any variables
requested by @code{for} or @code{with} have been bound to their
initial values).  @code{initially} clauses can appear anywhere;
if there are several, they are executed in the order they appear
in the loop.  The keyword @code{do} is optional.

@item finally [do] @var{forms}...
This introduces Lisp forms which will be executed after the loop
finishes (say, on request of a @code{for} or @code{while}).
@code{initially} and @code{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.

@item finally return @var{form}
This says that @var{form} should be executed after the loop
is done to obtain a return value.  (Without this, or some other
clause like @code{collect} or @code{return}, the loop will simply
return @code{nil}.)  Variables bound by @code{for}, @code{with},
or @code{into} will still contain their final values when @var{form}
is executed.

@item do @var{forms}...
The word @code{do} may be followed by any number of Lisp expressions
which are executed as an implicit @code{progn} in the body of the
loop.  Many of the examples in this section illustrate the use of
@code{do}.

@item return @var{form}
This clause causes the loop to return immediately.  The following
Lisp form is evaluated to give the return value of the @code{loop}
form.  The @code{finally} clauses, if any, are not executed.
Of course, @code{return} is generally used inside an @code{if} or
@code{unless}, as its use in a top-level loop clause would mean
the loop would never get to ``loop'' more than once.

The clause @samp{return @var{form}} is equivalent to
@samp{do (return @var{form})} (or @code{return-from} if the loop
was named).  The @code{return} clause is implemented a bit more
efficiently, though.
@end table

While there is no high-level way to add user extensions to @code{loop}
(comparable to @code{defsetf} for @code{setf}, say), this package
does offer two properties called @code{cl-loop-handler} and
@code{cl-loop-for-handler} which are functions to be called when
a given symbol is encountered as a top-level loop clause or
@code{for} clause, respectively.  Consult the source code in
file @file{cl-macs.el} for details.

This package's @code{loop} macro is compatible with that of Common
Lisp, except that a few features are not implemented:  @code{loop-finish}
and data-type specifiers.  Naturally, the @code{for} clauses which
iterate over keymaps, overlays, intervals, frames, windows, and
buffers are Emacs-specific extensions.

@node Multiple Values,  , Loop Facility, Control Structure
@section Multiple Values

@noindent
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
@code{compiler-macroexpand}) or return a list of values (as in
@code{get-setf-method}).  This package @emph{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 @code{values} form, for example, is a synonym for @code{list}
in Emacs.

@defspec multiple-value-bind (var@dots{}) values-form forms@dots{}
This form evaluates @var{values-form}, which must return a list of
values.  It then binds the @var{var}s to these respective values,
as if by @code{let}, and then executes the body @var{forms}.
If there are more @var{var}s than values, the extra @var{var}s
are bound to @code{nil}.  If there are fewer @var{var}s than
values, the excess values are ignored.
@end defspec

@defspec multiple-value-setq (var@dots{}) form
This form evaluates @var{form}, which must return a list of values.
It then sets the @var{var}s to these respective values, as if by
@code{setq}.  Extra @var{var}s or values are treated the same as
in @code{multiple-value-bind}.
@end defspec

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 @code{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.

@node Macros, Declarations, Control Structure, Top
@chapter Macros

@noindent
This package implements the various Common Lisp features of
@code{defmacro}, such as destructuring, @code{&environment},
and @code{&body}.  Top-level @code{&whole} is not implemented
for @code{defmacro} due to technical difficulties.
@xref{Argument Lists}.

Destructuring is made available to the user by way of the
following macro:

@defspec destructuring-bind arglist expr forms@dots{}
This macro expands to code which executes @var{forms}, with
the variables in @var{arglist} bound to the list of values
returned by @var{expr}.  The @var{arglist} can include all
the features allowed for @code{defmacro} argument lists,
including destructuring.  (The @code{&environment} keyword
is not allowed.)  The macro expansion will signal an error
if @var{expr} returns a list of the wrong number of arguments
or with incorrect keyword arguments.
@end defspec

This package also includes the Common Lisp @code{define-compiler-macro}
facility, which allows you to define compile-time expansions and
optimizations for your functions.

@defspec define-compiler-macro name arglist forms@dots{}
This form is similar to @code{defmacro}, except that it only expands
calls to @var{name} at compile-time; calls processed by the Lisp
interpreter are not expanded, nor are they expanded by the
@code{macroexpand} function.

The argument list may begin with a @code{&whole} keyword and a
variable.  This variable is bound to the macro-call form itself,
i.e., to a list of the form @samp{(@var{name} @var{args}@dots{})}.
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:

@example
(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))
@end example

@noindent
This definition causes @code{(member* @var{a} @var{list})} to change
to a call to the faster @code{memq} in the common case where @var{a}
is a non-floating-point constant; if @var{a} is anything else, or
if there are any keyword arguments in the call, then the original
@code{member*} call is left intact.  (The actual compiler macro
for @code{member*} optimizes a number of other cases, including
common @code{:test} predicates.)
@end defspec

@defun compiler-macroexpand form
This function is analogous to @code{macroexpand}, except that it
expands compiler macros rather than regular macros.  It returns
@var{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 @code{&whole} argument.  Like
@code{macroexpand}, it expands repeatedly until it reaches a form
for which no further expansion is possible.
@end defun

@xref{Macro Bindings}, for descriptions of the @code{macrolet}
and @code{symbol-macrolet} forms for making ``local'' macro
definitions.

@node Declarations, Symbols, Macros, Top
@chapter Declarations

@noindent
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:
@code{declare}, @code{locally}, @code{proclaim}, @code{declaim},
and @code{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 @code{special} declarations
are redundant in a fully dynamically-scoped Lisp.  A few
declarations are meaningful when the optimizing byte
compiler is being used, however.  Under the earlier non-optimizing
compiler, these declarations will effectively be ignored.

@defun proclaim decl-spec
This function records a ``global'' declaration specified by
@var{decl-spec}.  Since @code{proclaim} is a function, @var{decl-spec}
is evaluated and thus should normally be quoted.
@end defun

@defspec declaim decl-specs@dots{}
This macro is like @code{proclaim}, except that it takes any number
of @var{decl-spec} arguments, and the arguments are unevaluated and
unquoted.  The @code{declaim} macro also puts an @code{(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 @code{declaim}
form.)
@end defspec

@defspec declare decl-specs@dots{}
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 @code{progn}s''
throughout Lisp syntax, such as function bodies, @code{let} bodies,
etc.  Currently the only declaration understood by @code{declare}
is @code{special}.
@end defspec

@defspec locally declarations@dots{} forms@dots{}
In this package, @code{locally} is no different from @code{progn}.
@end defspec

@defspec the type form
Type information provided by @code{the} is ignored in this package;
in other words, @code{(the @var{type} @var{form})} is equivalent
to @var{form}.  Future versions of the optimizing byte-compiler may
make use of this information.

For example, @code{mapcar} can map over both lists and arrays.  It is
hard for the compiler to expand @code{mapcar} into an in-line loop
unless it knows whether the sequence will be a list or an array ahead
of time.  With @code{(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 @code{(mapcar 'car foo)}.
@end defspec

Each @var{decl-spec} in a @code{proclaim}, @code{declaim}, or
@code{declare} should be a list beginning with a symbol that says
what kind of declaration it is.  This package currently understands
@code{special}, @code{inline}, @code{notinline}, @code{optimize},
and @code{warn} declarations.  (The @code{warn} declaration is an
extension of standard Common Lisp.)  Other Common Lisp declarations,
such as @code{type} and @code{ftype}, are silently ignored.

@table @code
@item special
Since all variables in Emacs Lisp are ``special'' (in the Common
Lisp sense), @code{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 @code{(declare (special @var{var1} @var{var2}))} is
equivalent to @code{(defvar @var{var1}) (defvar @var{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
@code{(defvar @var{var})} than @code{(declaim (special @var{var}))},
since @code{defvar} makes your intentions clearer.  But the older
byte compilers can not handle @code{defvar}s appearing inside of
functions, while @code{(declare (special @var{var}))} takes care
to work correctly with all compilers.

@item inline
The @code{inline} @var{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 @code{cadr} is declared @code{inline}
by this package so that the form @code{(cadr @var{x})} will
expand directly into @code{(car (cdr @var{x}))} when it is called
in user functions, for a savings of one (relatively expensive)
function call.

The following declarations are all equivalent.  Note that the
@code{defsubst} form is a convenient way to define a function
and declare it inline all at once.

@example
(declaim (inline foo bar))
(eval-when (compile load eval) (proclaim '(inline foo bar)))
(defsubst foo (...) ...)       ; instead of defun
@end example

@strong{Please note:}  this declaration remains in effect after the
containing source file is done.  It is correct to use it to
request that a function you have defined should be inlined,
but it is impolite to use it to request inlining of an external
function.

In Common Lisp, it is possible to use @code{(declare (inline @dots{}))}
before a particular call to a function to cause just that call to
be inlined; the current byte compilers provide no way to implement
this, so @code{(declare (inline @dots{}))} is currently ignored by
this package.

@item notinline
The @code{notinline} declaration lists functions which should
not be inlined after all; it cancels a previous @code{inline}
declaration.

@item optimize
This declaration controls how much optimization is performed by
the compiler.  Naturally, it is ignored by the earlier non-optimizing
compilers.

The word @code{optimize} is followed by any number of lists like
@code{(speed 3)} or @code{(safety 2)}.  Common Lisp defines several
optimization ``qualities''; this package ignores all but @code{speed}
and @code{safety}.  The value of a quality should be an integer from
0 to 3, with 0 meaning ``unimportant'' and 3 meaning ``very important.''
The default level for both qualities is 1.

In this package, with the optimizing compiler, the
@code{speed} quality is tied to the @code{byte-compile-optimize}
flag, which is set to @code{nil} for @code{(speed 0)} and to
@code{t} for higher settings; and the @code{safety} quality is
tied to the @code{byte-compile-delete-errors} flag, which is
set to @code{t} for @code{(safety 3)} and to @code{nil} for all
lower settings.  (The latter flag controls whether the compiler
is allowed to optimize out code whose only side-effect could
be to signal an error, e.g., rewriting @code{(progn foo bar)} to
@code{bar} when it is not known whether @code{foo} will be bound
at run-time.)

Note that even compiling with @code{(safety 0)}, the Emacs
byte-code system provides sufficient checking to prevent real
harm from being done.  For example, barring serious bugs in
Emacs itself, Emacs will not crash with a segmentation fault
just because of an error in a fully-optimized Lisp program.

The @code{optimize} declaration is normally used in a top-level
@code{proclaim} or @code{declaim} in a file; Common Lisp allows
it to be used with @code{declare} to set the level of optimization
locally for a given form, but this will not work correctly with the
current version of the optimizing compiler.  (The @code{declare}
will set the new optimization level, but that level will not
automatically be unset after the enclosing form is done.)

@item warn
This declaration controls what sorts of warnings are generated
by the byte compiler.  Again, only the optimizing compiler
generates warnings.  The word @code{warn} is followed by any
number of ``warning qualities,'' similar in form to optimization
qualities.  The currently supported warning types are
@code{redefine}, @code{callargs}, @code{unresolved}, and
@code{free-vars}; in the current system, a value of 0 will
disable these warnings and any higher value will enable them.
See the documentation for the optimizing byte compiler for details.
@end table

@node Symbols, Numbers, Declarations, Top
@chapter Symbols

@noindent
This package defines several symbol-related features that were
missing from Emacs Lisp.

@menu
* Property Lists::       `get*', `remprop', `getf', `remf'
* Creating Symbols::     `gensym', `gentemp'
@end menu

@node Property Lists, Creating Symbols, Symbols, Symbols
@section Property Lists

@noindent
These functions augment the standard Emacs Lisp functions @code{get}
and @code{put} for operating on properties attached to symbols.
There are also functions for working with property lists as
first-class data structures not attached to particular symbols.

@defun get* symbol property &optional default
This function is like @code{get}, except that if the property is
not found, the @var{default} argument provides the return value.
(The Emacs Lisp @code{get} function always uses @code{nil} as
the default; this package's @code{get*} is equivalent to Common
Lisp's @code{get}.)

The @code{get*} function is @code{setf}-able; when used in this
fashion, the @var{default} argument is allowed but ignored.
@end defun

@defun remprop symbol property
This function removes the entry for @var{property} from the property
list of @var{symbol}.  It returns a true value if the property was
indeed found and removed, or @code{nil} if there was no such property.
(This function was probably omitted from Emacs originally because,
since @code{get} did not allow a @var{default}, it was very difficult
to distinguish between a missing property and a property whose value
was @code{nil}; thus, setting a property to @code{nil} was close
enough to @code{remprop} for most purposes.)
@end defun

@defun getf place property &optional default
This function scans the list @var{place} as if it were a property
list, i.e., a list of alternating property names and values.  If
an even-numbered element of @var{place} is found which is @code{eq}
to @var{property}, the following odd-numbered element is returned.
Otherwise, @var{default} is returned (or @code{nil} if no default
is given).

In particular,

@example
(get sym prop)  @equiv{}  (getf (symbol-plist sym) prop)
@end example

It is valid to use @code{getf} as a @code{setf} place, in which case
its @var{place} argument must itself be a valid @code{setf} place.
The @var{default} argument, if any, is ignored in this context.
The effect is to change (via @code{setcar}) the value cell in the
list that corresponds to @var{property}, or to cons a new property-value
pair onto the list if the property is not yet present.

@example
(put sym prop val)  @equiv{}  (setf (getf (symbol-plist sym) prop) val)
@end example

The @code{get} and @code{get*} functions are also @code{setf}-able.
The fact that @code{default} is ignored can sometimes be useful:

@example
(incf (get* 'foo 'usage-count 0))
@end example

Here, symbol @code{foo}'s @code{usage-count} property is incremented
if it exists, or set to 1 (an incremented 0) otherwise.

When not used as a @code{setf} form, @code{getf} is just a regular
function and its @var{place} argument can actually be any Lisp
expression.
@end defun

@defspec remf place property
This macro removes the property-value pair for @var{property} from
the property list stored at @var{place}, which is any @code{setf}-able
place expression.  It returns true if the property was found.  Note
that if @var{property} happens to be first on the list, this will
effectively do a @code{(setf @var{place} (cddr @var{place}))},
whereas if it occurs later, this simply uses @code{setcdr} to splice
out the property and value cells.
@end defspec

@iftex
@secno=2
@end iftex

@node Creating Symbols,  , Property Lists, Symbols
@section Creating Symbols

@noindent
These functions create unique symbols, typically for use as
temporary variables.

@defun gensym &optional x
This function creates a new, uninterned symbol (using @code{make-symbol})
with a unique name.  (The name of an uninterned symbol is relevant
only if the symbol is printed.)  By default, the name is generated
from an increasing sequence of numbers, @samp{G1000}, @samp{G1001},
@samp{G1002}, etc.  If the optional argument @var{x} is a string, that
string is used as a prefix instead of @samp{G}.  Uninterned symbols
are used in macro expansions for temporary variables, to ensure that
their names will not conflict with ``real'' variables in the user's
code.
@end defun

@defvar *gensym-counter*
This variable holds the counter used to generate @code{gensym} names.
It is incremented after each use by @code{gensym}.  In Common Lisp
this is initialized with 0, but this package initializes it with a
random (time-dependent) value to avoid trouble when two files that
each used @code{gensym} in their compilation are loaded together.
(Uninterned symbols become interned when the compiler writes them
out to a file and the Emacs loader loads them, so their names have to
be treated a bit more carefully than in Common Lisp where uninterned
symbols remain uninterned after loading.)
@end defvar

@defun gentemp &optional x
This function is like @code{gensym}, except that it produces a new
@emph{interned} symbol.  If the symbol that is generated already
exists, the function keeps incrementing the counter and trying
again until a new symbol is generated.
@end defun

The Quiroz @file{cl.el} package also defined a @code{defkeyword}
form for creating self-quoting keyword symbols.  This package
automatically creates all keywords that are called for by
@code{&key} argument specifiers, and discourages the use of
keywords as data unrelated to keyword arguments, so the
@code{defkeyword} form has been discontinued.

@iftex
@chapno=11
@end iftex

@node Numbers, Sequences, Symbols, Top
@chapter Numbers

@noindent
This section defines a few simple Common Lisp operations on numbers
which were left out of Emacs Lisp.

@menu
* Predicates on Numbers::       `plusp', `oddp', `floatp-safe', etc.
* Numerical Functions::         `abs', `floor*', etc.
* Random Numbers::              `random*', `make-random-state'
* Implementation Parameters::   `most-positive-float'
@end menu

@iftex
@secno=1
@end iftex

@node Predicates on Numbers, Numerical Functions, Numbers, Numbers
@section Predicates on Numbers

@noindent
These functions return @code{t} if the specified condition is
true of the numerical argument, or @code{nil} otherwise.

@defun plusp number
This predicate tests whether @var{number} is positive.  It is an
error if the argument is not a number.
@end defun

@defun minusp number
This predicate tests whether @var{number} is negative.  It is an
error if the argument is not a number.
@end defun

@defun oddp integer
This predicate tests whether @var{integer} is odd.  It is an
error if the argument is not an integer.
@end defun

@defun evenp integer
This predicate tests whether @var{integer} is even.  It is an
error if the argument is not an integer.
@end defun

@defun floatp-safe object
This predicate tests whether @var{object} is a floating-point
number.  On systems that support floating-point, this is equivalent
to @code{floatp}.  On other systems, this always returns @code{nil}.
@end defun

@iftex
@secno=3
@end iftex

@node Numerical Functions, Random Numbers, Predicates on Numbers, Numbers
@section Numerical Functions

@noindent
These functions perform various arithmetic operations on numbers.

@defun gcd &rest integers
This function returns the Greatest Common Divisor of the ar