mirror of
https://git.savannah.gnu.org/git/emacs.git
synced 2024-11-22 07:09:54 +00:00
5384 lines
209 KiB
Plaintext
5384 lines
209 KiB
Plaintext
\input texinfo @c -*-texinfo-*-
|
|
@setfilename ../../info/cl.info
|
|
@settitle Common Lisp Extensions
|
|
@include docstyle.texi
|
|
@include emacsver.texi
|
|
|
|
@copying
|
|
This file documents the GNU Emacs Common Lisp emulation package.
|
|
|
|
Copyright @copyright{} 1993, 2001--2024 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.3 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''.
|
|
|
|
(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
|
|
modify this GNU manual.''
|
|
@end quotation
|
|
@end copying
|
|
|
|
@dircategory Emacs lisp libraries
|
|
@direntry
|
|
* CL-Lib: (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 as distributed with Emacs @value{EMACSVER}
|
|
@sp 5
|
|
@center Dave Gillespie
|
|
@center daveg@@synaptics.com
|
|
@page
|
|
@vskip 0pt plus 1filll
|
|
@insertcopying
|
|
@end titlepage
|
|
|
|
@contents
|
|
|
|
@ifnottex
|
|
@node Top
|
|
@top GNU Emacs Common Lisp Emulation
|
|
|
|
@insertcopying
|
|
@end ifnottex
|
|
|
|
@menu
|
|
* Overview:: Basics, usage, organization, naming conventions.
|
|
* Printing:: Human friendly printing with @code{cl-prin1}.
|
|
* Program Structure:: Arglists, @code{cl-eval-when}.
|
|
* Predicates:: Type predicates and equality predicates.
|
|
* Control Structure:: Assignment, conditionals, blocks, looping.
|
|
* Macros:: Destructuring, compiler macros.
|
|
* Declarations:: @code{cl-proclaim}, @code{cl-declare}, etc.
|
|
* Symbols:: Property lists, creating symbols.
|
|
* Numbers:: Predicates, functions, random numbers.
|
|
* Sequences:: Mapping, functions, searching, sorting.
|
|
* Lists:: Functions, substitution, sets, associations.
|
|
* Structures:: @code{cl-defstruct}.
|
|
* Assertions:: Assertions and type checking.
|
|
|
|
Appendices
|
|
* Efficiency Concerns:: Hints and techniques.
|
|
* Common Lisp Compatibility:: All known differences with Steele.
|
|
* Porting Common Lisp:: Hints for porting Common Lisp code.
|
|
* Obsolete Features:: Obsolete features.
|
|
* GNU Free Documentation License:: The license for this documentation.
|
|
|
|
Indexes
|
|
* Function Index:: An entry for each documented function.
|
|
* Variable Index:: An entry for each documented variable.
|
|
* Concept Index:: An entry for each concept.
|
|
@end menu
|
|
|
|
@node Overview
|
|
@chapter Overview
|
|
|
|
@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.
|
|
|
|
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, it adds enough functionality
|
|
to make Emacs Lisp programming significantly more convenient.
|
|
|
|
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. (The separate package EIEIO implements
|
|
a subset of CLOS functionality. @xref{Top, , Introduction, eieio, EIEIO}.)
|
|
|
|
@item
|
|
Other features cannot be implemented without modification to the
|
|
Emacs Lisp interpreter itself, such as multiple return values,
|
|
case-insensitive symbols, and complex numbers.
|
|
This package generally makes no attempt to emulate these features.
|
|
|
|
@end itemize
|
|
|
|
This package was originally written by Dave Gillespie,
|
|
@file{daveg@@synaptics.com}, as a total rewrite of an earlier 1986
|
|
@file{cl.el} package by Cesar Quiroz. Care has been taken to ensure
|
|
that each function is defined efficiently, concisely, and with minimal
|
|
impact on the rest of the Emacs environment. Stefan Monnier added the
|
|
file @file{cl-lib.el} and rationalized the namespace for Emacs 24.3.
|
|
|
|
@menu
|
|
* Usage:: How to use this package.
|
|
* Organization:: The package's component files.
|
|
* Naming Conventions:: Notes on function names.
|
|
@end menu
|
|
|
|
@node Usage
|
|
@section Usage
|
|
|
|
@noindent
|
|
This package is distributed with Emacs, so there is no need
|
|
to install any additional files in order to start using it. Lisp code
|
|
that uses features from this package should simply include at
|
|
the beginning:
|
|
|
|
@example
|
|
(require 'cl-lib)
|
|
@end example
|
|
|
|
@noindent
|
|
You may wish to add such a statement to your init file, if you
|
|
make frequent use of features from this package.
|
|
|
|
Code that only uses macros from this package can enclose the above in
|
|
@code{eval-when-compile}. Internally, this library is divided into
|
|
several files, @pxref{Organization}. Your code should only ever load
|
|
the main @file{cl-lib} file, which will load the others as needed.
|
|
|
|
@node Organization
|
|
@section Organization
|
|
|
|
@noindent
|
|
The Common Lisp package is organized into four main files:
|
|
|
|
@table @file
|
|
@item cl-lib.el
|
|
This is the main file, which contains basic functions
|
|
and information about the package. This file is relatively compact.
|
|
|
|
@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{cl-incf} 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{cl-delete-if} and @code{cl-assoc}.
|
|
|
|
@item cl-macs.el
|
|
This file contains the features that 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). 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-lib.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-lib)}, and @file{cl-lib.el}
|
|
will take care of pulling in the other files when they are
|
|
needed.
|
|
|
|
There is another file, @file{cl.el}, which was the main entry point to
|
|
this package prior to Emacs 24.3. Nowadays, it is replaced by
|
|
@file{cl-lib.el}. The two provide the same features (in most cases),
|
|
but use different function names (in fact, @file{cl.el} mainly just
|
|
defines aliases to the @file{cl-lib.el} definitions). Where
|
|
@file{cl-lib.el} defines a function called, for example,
|
|
@code{cl-incf}, @file{cl.el} uses the same name but without the
|
|
@samp{cl-} prefix, e.g., @code{incf} in this example. There are a few
|
|
exceptions to this. First, functions such as @code{cl-defun} where
|
|
the unprefixed version was already used for a standard Emacs Lisp
|
|
function. In such cases, the @file{cl.el} version adds a @samp{*}
|
|
suffix, e.g., @code{defun*}. Second, there are some obsolete features
|
|
that are only implemented in @file{cl.el}, not in @file{cl-lib.el},
|
|
because they are replaced by other standard Emacs Lisp features.
|
|
Finally, in a very few cases the old @file{cl.el} versions do not
|
|
behave in exactly the same way as the @file{cl-lib.el} versions.
|
|
@xref{Obsolete Features}.
|
|
@c There is also cl-mapc, which was called cl-mapc even before cl-lib.el.
|
|
@c But not autoloaded, so maybe not much used?
|
|
|
|
The old file @file{cl.el}, as well as the even older
|
|
@file{cl-compat.el}, are deprecated and will be removed in a future
|
|
version of Emacs. Any existing code that uses them should be updated
|
|
to use @file{cl-lib.el} instead.
|
|
|
|
@node Naming Conventions
|
|
@section Naming Conventions
|
|
|
|
@noindent
|
|
Except where noted, all functions defined by this package have the
|
|
same calling conventions as their Common Lisp counterparts, and
|
|
names that are those of Common Lisp plus a @samp{cl-} prefix.
|
|
|
|
Internal function and variable names in the package are prefixed
|
|
by @code{cl--}. Here is a complete list of functions prefixed by
|
|
@code{cl-} that were @emph{not} taken from Common Lisp:
|
|
|
|
@example
|
|
cl-callf cl-callf2 cl-defsubst
|
|
cl-letf cl-letf*
|
|
@end example
|
|
|
|
@c This is not uninteresting I suppose, but is of zero practical relevance
|
|
@c to the user, and seems like a hostage to changing implementation details.
|
|
The following simple functions and macros are defined in @file{cl-lib.el};
|
|
they do not cause other components like @file{cl-extra} to be loaded.
|
|
|
|
@example
|
|
cl-evenp cl-oddp cl-minusp
|
|
cl-plusp cl-endp cl-subst
|
|
cl-copy-list cl-list* cl-ldiff
|
|
cl-rest cl-decf [1] cl-incf [1]
|
|
cl-acons cl-adjoin [2] cl-pairlis
|
|
cl-pushnew [1,2] cl-declaim cl-proclaim
|
|
cl-caaar@dots{}cl-cddddr cl-first@dots{}cl-tenth
|
|
cl-mapcar [3]
|
|
@end example
|
|
|
|
@noindent
|
|
[1] Only when @var{place} is a plain variable name.
|
|
|
|
@noindent
|
|
[2] Only if @code{:test} is @code{eq}, @code{equal}, or unspecified,
|
|
and @code{:key} is not used.
|
|
|
|
@noindent
|
|
[3] Only for one sequence argument or two list arguments.
|
|
|
|
@node Printing
|
|
@chapter Printing
|
|
|
|
@noindent
|
|
This chapter describes some enhancements to Emacs Lisp's
|
|
@dfn{printing}, the action of representing Lisp objects in text form.
|
|
The functions documented here are intended to produce output more for
|
|
human readers than the standard printing functions such as
|
|
@code{prin1} and @code{princ} (@pxref{Output Functions,,,elisp,GNU
|
|
Emacs Lisp Reference Manual}).
|
|
|
|
Several of these functions have a parameter @var{stream}; this
|
|
specifies what to do with the characters printing produces. For
|
|
example, it might be a buffer, a marker, @code{nil} (meaning use
|
|
standard output), or @code{t} (use the echo area). @xref{Output
|
|
Streams,,,elisp,GNU Emacs Lisp Reference Manual}, for a full
|
|
description.
|
|
|
|
@defvar cl-print-readably
|
|
When this variable is non-@code{nil}, @code{cl-prin1} and other
|
|
functions described here try to produce output which can later be read
|
|
by the Lisp reader (@pxref{Input Functions,,,elisp,GNU Emacs Lisp
|
|
Reference Manual}).
|
|
@end defvar
|
|
|
|
@defvar cl-print-compiled
|
|
This variable controls how to print byte-compiled functions. Valid
|
|
values are:
|
|
@table @code
|
|
@item nil
|
|
The default: Just an internal hex identifier is printed.
|
|
@item static
|
|
The internal hex identifier together with the function's constant
|
|
vector are printed.
|
|
@item disassemble
|
|
The byte code gets disassembled.
|
|
@item raw
|
|
The raw form of the function is printed by @code{prin1}.
|
|
@end table
|
|
|
|
Sometimes, a button is set on the output to allow you to disassemble
|
|
the function. See @code{cl-print-compile-button}.
|
|
@end defvar
|
|
|
|
@defvar cl-print-compile-button
|
|
When this variable is non-@code{nil} and a byte-compiled function has
|
|
been printed to a buffer, you can click with the mouse or type
|
|
@key{RET} on that output to disassemble the code. This doesn't apply
|
|
when @code{cl-print-compiled} is set to @code{disassemble}.
|
|
@end defvar
|
|
|
|
@defvar cl-print-string-length
|
|
The maximum length of a string to print before abbreviating it. A
|
|
value of @code{nil}, the default, means no limit.
|
|
|
|
When the CL printing functions abbreviate a string, they print the
|
|
first @code{cl-print-string-length} characters of the string, followed
|
|
by ``@enddots{}''. When the printing is to a buffer, you can click
|
|
with the mouse or type @key{RET} on this ellipsis to expand the
|
|
string.
|
|
|
|
This variable has effect only in the @code{cl-prin*} functions, not in
|
|
primitives such as @code{prin1}.
|
|
@end defvar
|
|
|
|
@defun cl-prin1 object &option stream
|
|
@code{cl-print1} prints @var{object} on @var{stream} (see above)
|
|
according to its type and the settings described above. The variables
|
|
@code{print-length} and @code{print-level} and the other standard
|
|
Emacs settings also affect the printing (@pxref{Output
|
|
Variables,,,elisp,GNU Emacs Lisp Reference Manual}).
|
|
@end defun
|
|
|
|
@defun cl-prin1-to-string object
|
|
This function is like @code{cl-prin1}, except the output characters
|
|
are returned as a string from this function rather than being passed
|
|
to a stream.
|
|
@end defun
|
|
|
|
@defun cl-print-to-string-with-limit print-function value limit
|
|
This function returns a string containing a printed representation of
|
|
@var{value}. It attempts to get the length of the returned string
|
|
under @var{limit} characters with successively more restrictive
|
|
settings of @code{print-level}, @code{print-length}, and
|
|
@code{cl-print-string-length}. It uses @var{print-function} to print,
|
|
a function which should take the arguments @var{value} and a stream
|
|
(see above), and which should respect @code{print-length},
|
|
@code{print-level}, and @code{cl-print-string-length}. @var{limit}
|
|
may be @code{nil} or zero, in which case @var{print-function} will be
|
|
called with these settings bound to @code{nil}; it can also be
|
|
@code{t}, in which case @var{print-function} will be called with their
|
|
current values.
|
|
|
|
Use this function with @code{cl-prin1} to print an object, possibly
|
|
abbreviating it with one or more ellipses to fit within the size
|
|
limit.
|
|
@end defun
|
|
|
|
@defun cl-print-object object stream
|
|
This function prints @var{object} on @var{stream} (see above). It is
|
|
actually a @code{cl-defgeneric} (@pxref{Generic Functions,,,elisp,GNU
|
|
Emacs Lisp Reference Manual}), which is defined for several types of
|
|
@var{object}. Normally, you just call @code{cl-prin1} to print an
|
|
@var{object} rather than calling this function directly.
|
|
|
|
You can write @code{cl-print-object} @code{cl-defmethod}s for other
|
|
types of @var{object}, thus extending @code{cl-prin1}. If such a
|
|
method uses ellipses, you should also write a
|
|
@code{cl-print-object-contents} method for the same type. For
|
|
examples of these methods, see @file{emacs-lisp/cl-print.el} in the
|
|
Emacs source directory.
|
|
@end defun
|
|
|
|
@defun cl-print-object-contents object start stream
|
|
This function replaces an ellipsis in @var{stream} beginning at
|
|
@var{start} with the text from the partially printed @var{object} it
|
|
represents. It is also a @code{cl-defgeneric} defined for several
|
|
types of @var{object}. @var{stream} is a buffer containing the text
|
|
with the ellipsis. @var{start} specifies the starting position of the
|
|
ellipsis in a manner dependent on the type; it will have been obtained
|
|
from a text property on the ellipsis, having been put there by
|
|
@code{cl-print-insert-ellipsis}.
|
|
@end defun
|
|
|
|
@defun cl-print-insert-ellipsis object start stream
|
|
This function prints an ellipsis (``@dots{}'') to @var{stream} (see
|
|
above). When @var{stream} is a buffer, the ellipsis will be given the
|
|
@code{cl-print-ellipsis} text property. The value of the text
|
|
property will contain state (including @var{start}) in order to print
|
|
the elided part of @var{object} later. @var{start} should be nil if
|
|
the whole @var{object} is being elided, otherwise it should be an
|
|
index or other pointer into the internals of @var{object} which can be
|
|
passed to `cl-print-object-contents' at a later time.
|
|
@end defun
|
|
|
|
@defvar cl-print-expand-ellipsis-function
|
|
This variable holds a function which expands an ellipsis in the
|
|
current buffer. The function takes four arguments: @var{begin} and
|
|
@var{end}, which are the bounds of the ellipsis; @var{value}, which is
|
|
the value of the @code{cl-print-ellipsis} text property on the
|
|
ellipsis (typically set earlier by @code{cl-prin1}); and
|
|
@var{line-length}, the desired maximum length of the output. Its
|
|
return value is the buffer position after the expanded text.
|
|
@end defvar
|
|
|
|
@deffn Command cl-print-expand-ellipsis &optional button
|
|
This command expands the ellipsis at point. Non-interactively, if
|
|
@var{button} is non-@code{nil}, it should be either a buffer position
|
|
or a button made by @code{cl-print-insert-ellipsis}
|
|
(@pxref{Buttons,,,elisp,GNU Emacs Lisp Reference Manual}), which
|
|
indicates the position of the ellipsis. The return value is the
|
|
buffer position after the expanded text.
|
|
@end deffn
|
|
|
|
@node Program Structure
|
|
@chapter Program Structure
|
|
|
|
@noindent
|
|
This section describes features of this package that have to
|
|
do with programs as a whole: advanced argument lists for functions,
|
|
and the @code{cl-eval-when} construct.
|
|
|
|
@menu
|
|
* Argument Lists:: @code{&key}, @code{&aux}, @code{cl-defun}, @code{cl-defmacro}.
|
|
* Time of Evaluation:: The @code{cl-eval-when} construct.
|
|
@end menu
|
|
|
|
@node Argument Lists
|
|
@section Argument Lists
|
|
@cindex &key
|
|
@cindex &aux
|
|
|
|
@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.
|
|
|
|
@defmac cl-defun name arglist body@dots{}
|
|
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 defmac
|
|
|
|
@defmac cl-iter-defun name arglist body@dots{}
|
|
This form is identical to the regular @code{iter-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 defmac
|
|
|
|
@defmac cl-defsubst name arglist body@dots{}
|
|
This is just like @code{cl-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{cl-defsubst} uses a different method (compiler macros) which
|
|
works in all versions of Emacs, and also generates somewhat more
|
|
@c For some examples,
|
|
@c see https://lists.gnu.org/r/emacs-devel/2012-11/msg00009.html
|
|
efficient inline expansions. In particular, @code{cl-defsubst}
|
|
arranges for the processing of keyword arguments, default values,
|
|
etc., to be done at compile-time whenever possible.
|
|
@end defmac
|
|
|
|
@cindex &allow-other-keys
|
|
@defmac cl-defmacro name arglist body@dots{}
|
|
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's book @cite{Common Lisp, the Language}.
|
|
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 defmac
|
|
|
|
@defmac cl-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 defmac
|
|
|
|
Also, all forms (such as @code{cl-flet} and @code{cl-labels}) 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{cl-defun} in
|
|
order to have access to most CL features in your function.
|
|
These features are always present; @code{cl-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}@dots{}
|
|
&optional (@var{var} @var{initform} @var{svar})@dots{}
|
|
&rest @var{var}
|
|
&key ((@var{keyword} @var{var}) @var{initform} @var{svar})@dots{}
|
|
&aux (@var{var} @var{initform})@dots{})
|
|
@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
|
|
(cl-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.
|
|
|
|
You can also explicitly specify the keyword argument; it need not be
|
|
simply the variable name prefixed with a colon. For example,
|
|
|
|
@example
|
|
(cl-defun bar (&key (a 1) ((baz b) 4)))
|
|
@end example
|
|
|
|
@noindent
|
|
|
|
specifies a keyword @code{:a} that sets the variable @code{a} with
|
|
default value 1, as well as a keyword @code{baz} that sets the
|
|
variable @code{b} with default value 4. In this case, because
|
|
@code{baz} is not self-quoting, you must quote it explicitly in the
|
|
function call, like this:
|
|
|
|
@example
|
|
(bar :a 10 'baz 42)
|
|
@end example
|
|
|
|
@cindex &allow-other-keys
|
|
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:
|
|
|
|
@example
|
|
(cl-defun find-thing (thing thing-list &rest rest &key need &allow-other-keys)
|
|
(or (apply 'cl-member thing thing-list :allow-other-keys t rest)
|
|
(if need (error "Thing not found"))))
|
|
@end example
|
|
|
|
@noindent
|
|
This function takes a @code{:need} keyword argument, but also
|
|
accepts other keyword arguments which are passed on to the
|
|
@code{cl-member} function. @code{allow-other-keys} is used to
|
|
keep both @code{find-thing} and @code{cl-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
|
|
(cl-defun foo (a b &aux (c (+ a b)) d)
|
|
@var{body})
|
|
|
|
(cl-defun foo (a b)
|
|
(let ((c (+ a b)) d)
|
|
@var{body}))
|
|
@end example
|
|
|
|
@cindex destructuring, in argument list
|
|
Argument lists support @dfn{destructuring}. In Common Lisp,
|
|
destructuring is only allowed with @code{defmacro}; this package
|
|
allows it with @code{cl-defun} and other argument lists as well.
|
|
In destructuring, any argument variable (@var{var} in the above
|
|
example) 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
|
|
(cl-defmacro dolist ((var listform &optional resultform)
|
|
&rest body)
|
|
@dots{})
|
|
@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
|
|
@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.
|
|
|
|
@defmac cl-eval-when (situations@dots{}) forms@dots{}
|
|
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{cl-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{cl-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{cl-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{cl-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:
|
|
(cl-eval-when (compile) (setq foo1 'bar))
|
|
(cl-eval-when (load) (setq foo2 'bar))
|
|
(cl-eval-when (compile load) (setq foo3 'bar))
|
|
(cl-eval-when (eval) (setq foo4 'bar))
|
|
(cl-eval-when (eval compile) (setq foo5 'bar))
|
|
(cl-eval-when (eval load) (setq foo6 'bar))
|
|
(cl-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{cl-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{(cl-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{(cl-eval-when
|
|
(compile load eval) @dots{})}.
|
|
@end defmac
|
|
|
|
Emacs includes two special forms related to @code{cl-eval-when}.
|
|
@xref{Eval During Compile,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
One of these, @code{eval-when-compile}, is not quite equivalent to
|
|
any @code{cl-eval-when} construct and is described below.
|
|
|
|
The other form, @code{(eval-and-compile @dots{})}, is exactly
|
|
equivalent to @samp{(cl-eval-when (compile load eval) @dots{})}.
|
|
|
|
@defmac eval-when-compile forms@dots{}
|
|
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 defmac
|
|
|
|
@defmac cl-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{cl-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{cl-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: "
|
|
(cl-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 Oct 31 16:32:28 2012"
|
|
", and loaded on: "
|
|
--temp--))
|
|
@end example
|
|
@end defmac
|
|
|
|
@node Predicates
|
|
@chapter Predicates
|
|
|
|
@noindent
|
|
This section describes functions for testing whether various
|
|
facts are true or false.
|
|
|
|
@menu
|
|
* Type Predicates:: @code{cl-typep}, @code{cl-deftype}, and @code{cl-coerce}.
|
|
* Equality Predicates:: @code{cl-equalp}.
|
|
@end menu
|
|
|
|
@node Type Predicates
|
|
@section Type Predicates
|
|
|
|
@defun cl-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{(cl-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{(cl-typep @var{object} t)} is always true. Likewise, the
|
|
type symbol @code{nil} stands for nothing at all, and
|
|
@code{(cl-typep @var{object} nil)} is always false.
|
|
|
|
@item
|
|
The type symbol @code{null} represents the symbol @code{nil}.
|
|
Thus @code{(cl-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{(cl-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 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{cl-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{cl-typep}.
|
|
|
|
@defun cl-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{cl-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{cl-coerce} signals an
|
|
error.
|
|
@end defun
|
|
|
|
@defmac cl-deftype name arglist forms@dots{}
|
|
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{cl-defmacro}. The type specifier @samp{(@var{name} @var{args}@dots{})}
|
|
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{cl-defmacro} except that optional arguments without explicit
|
|
defaults use @code{*} instead of @code{nil} as the ``default''
|
|
default. Some examples:
|
|
|
|
@example
|
|
(cl-deftype null () '(satisfies null)) ; predefined
|
|
(cl-deftype list () '(or null cons)) ; predefined
|
|
(cl-deftype unsigned-byte (&optional bits)
|
|
(list 'integer 0 (if (eq bits '*) bits (1- (ash 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 defmac
|
|
|
|
The @code{cl-typecase} (@pxref{Conditionals}) and @code{cl-check-type}
|
|
(@pxref{Assertions}) macros also use type names. The @code{cl-map},
|
|
@code{cl-concatenate}, and @code{cl-merge} functions take type-name
|
|
arguments to specify the type of sequence to return. @xref{Sequences}.
|
|
|
|
@node Equality Predicates
|
|
@section Equality Predicates
|
|
|
|
@noindent
|
|
This package defines the Common Lisp predicate @code{cl-equalp}.
|
|
|
|
@defun cl-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{(cl-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{cl-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.
|
|
The functions @code{cl-member} and @code{cl-assoc} use @code{eql},
|
|
as in Common Lisp. The standard Emacs Lisp functions @code{memq} and
|
|
@code{assq} use @code{eq}, and the standard @code{memql} uses @code{eql}.
|
|
|
|
@node Control Structure
|
|
@chapter Control Structure
|
|
|
|
@noindent
|
|
The features described in the following sections implement
|
|
various advanced control structures, including extensions to the
|
|
standard @code{setf} facility, and a number of looping and conditional
|
|
constructs.
|
|
|
|
@menu
|
|
* Assignment:: The @code{cl-psetq} form.
|
|
* Generalized Variables:: Extensions to generalized variables.
|
|
* Variable Bindings:: @code{cl-progv}, @code{cl-flet}, @code{cl-macrolet}.
|
|
* Conditionals:: @code{cl-case}, @code{cl-typecase}.
|
|
* Blocks and Exits:: @code{cl-block}, @code{cl-return}, @code{cl-return-from}.
|
|
* Iteration:: @code{cl-do}, @code{cl-dotimes}, @code{cl-dolist}, @code{cl-do-symbols}.
|
|
* Loop Facility:: The Common Lisp @code{loop} macro.
|
|
* Multiple Values:: @code{cl-values}, @code{cl-multiple-value-bind}, etc.
|
|
* Macro-Writing Macros:: @code{cl-with-gensyms}, @code{cl-once-only}.
|
|
@end menu
|
|
|
|
@node Assignment
|
|
@section Assignment
|
|
|
|
@noindent
|
|
The @code{cl-psetq} form is just like @code{setq}, except that multiple
|
|
assignments are done in parallel rather than sequentially.
|
|
|
|
@defmac cl-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)
|
|
(cl-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{cl-psetq} is @code{(cl-psetq x y y x)}, which
|
|
exchanges the values of two variables. (The @code{cl-rotatef} form
|
|
provides an even more convenient way to swap two variables;
|
|
@pxref{Modify Macros}.)
|
|
|
|
@code{cl-psetq} always returns @code{nil}.
|
|
@end defmac
|
|
|
|
@node Generalized Variables
|
|
@section Generalized Variables
|
|
@cindex generalized variable
|
|
|
|
A @dfn{generalized variable} or @dfn{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 @sc{car}s and @sc{cdr}s of lists,
|
|
elements of arrays, properties of symbols, and many other locations
|
|
are also places where Lisp values are stored. For basic information,
|
|
@pxref{Generalized Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
This package provides several additional features related to
|
|
generalized variables.
|
|
|
|
@menu
|
|
* Setf Extensions:: Additional @code{setf} places.
|
|
* Modify Macros:: @code{cl-incf}, @code{cl-rotatef}, @code{cl-letf}, @code{cl-callf}, etc.
|
|
@end menu
|
|
|
|
@node Setf Extensions
|
|
@subsection Setf Extensions
|
|
|
|
Several standard (e.g., @code{car}) and Emacs-specific
|
|
(e.g., @code{window-point}) Lisp functions are @code{setf}-able by default.
|
|
This package defines @code{setf} handlers for several additional functions:
|
|
|
|
@itemize
|
|
@item
|
|
Functions from this package:
|
|
@example
|
|
cl-rest cl-subseq cl-get cl-getf
|
|
cl-caaar@dots{}cl-cddddr cl-first@dots{}cl-tenth
|
|
@end example
|
|
|
|
@noindent
|
|
Note that for @code{cl-getf} (as for @code{nthcdr}), the list argument
|
|
of the function must itself be a valid @var{place} form.
|
|
|
|
@c Currently commented out in cl.el.
|
|
@ignore
|
|
@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}.
|
|
@xref{Obsolete Setf Customization}.
|
|
@end ignore
|
|
|
|
@c FIXME? Is this still true?
|
|
@item
|
|
A macro call, in which case the macro is expanded and @code{setf}
|
|
is applied to the resulting form.
|
|
@end itemize
|
|
|
|
@c FIXME should this be in lispref? It seems self-evident.
|
|
@c Contrast with the cl-incf example later on.
|
|
@c Here it really only serves as a contrast to wrong-order.
|
|
The @code{setf} macro takes care to evaluate all subforms in
|
|
the proper left-to-right order; for example,
|
|
|
|
@example
|
|
(setf (aref vec (cl-incf i)) i)
|
|
@end example
|
|
|
|
@noindent
|
|
looks like it will evaluate @code{(cl-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}.
|
|
|
|
@node Modify Macros
|
|
@subsection Modify Macros
|
|
|
|
@noindent
|
|
This package defines a number of macros that operate on generalized
|
|
variables. Many are interesting and useful even when the @var{place}
|
|
is just a variable name.
|
|
|
|
@defmac cl-psetf [place form]@dots{}
|
|
This macro is to @code{setf} what @code{cl-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 defmac
|
|
|
|
@defmac cl-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{(cl-incf i)} is equivalent to @code{(setq i (1+ i))}, and
|
|
@code{(cl-incf (car x) 2)} is equivalent to @code{(setcar x (+ (car x) 2))}.
|
|
|
|
As with @code{setf}, care is taken to preserve the ``apparent'' order
|
|
of evaluation. For example,
|
|
|
|
@example
|
|
(cl-incf (aref vec (cl-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 (cl-incf i))
|
|
(1+ (aref vec (cl-incf i)))) ; wrong!
|
|
@end example
|
|
|
|
@noindent
|
|
but rather to something more like
|
|
|
|
@example
|
|
(let ((temp (cl-incf i)))
|
|
(setf (aref vec temp) (1+ (aref vec temp))))
|
|
@end example
|
|
|
|
@noindent
|
|
Again, all of this is taken care of automatically by @code{cl-incf} and
|
|
the other generalized-variable macros.
|
|
|
|
As a more Emacs-specific example of @code{cl-incf}, the expression
|
|
@code{(cl-incf (point) @var{n})} is essentially equivalent to
|
|
@code{(forward-char @var{n})}.
|
|
@end defmac
|
|
|
|
@defmac cl-decf place &optional x
|
|
This macro decrements the number stored in @var{place} by one, or
|
|
by @var{x} if specified.
|
|
@end defmac
|
|
|
|
@defmac cl-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} isn't present in the list already.
|
|
The optional keyword arguments are interpreted in the same way as for
|
|
@code{cl-adjoin}. @xref{Lists as Sets}.
|
|
@end defmac
|
|
|
|
@defmac cl-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{(cl-shiftf @var{a} @var{b} @var{c}
|
|
@var{d})} is equivalent to
|
|
|
|
@example
|
|
(prog1
|
|
@var{a}
|
|
(cl-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 defmac
|
|
|
|
@defmac cl-rotatef place@dots{}
|
|
This macro rotates the @var{place}s left by one in circular fashion.
|
|
Thus, @code{(cl-rotatef @var{a} @var{b} @var{c} @var{d})} is equivalent to
|
|
|
|
@example
|
|
(cl-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{cl-rotatef} always
|
|
returns @code{nil}. Note that @code{(cl-rotatef @var{a} @var{b})}
|
|
conveniently exchanges @var{a} and @var{b}.
|
|
@end defmac
|
|
|
|
The following macros were invented for this package; they have no
|
|
analogues in Common Lisp.
|
|
|
|
@defmac cl-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
|
|
(cl-letf (((point) (point-min))
|
|
(a 17))
|
|
@dots{})
|
|
@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{cl-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{cl-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.)
|
|
|
|
Like in the case of @code{let}, the @var{value} forms are evaluated in
|
|
the order they appear, but the order of bindings is unspecified.
|
|
Therefore, avoid binding the same @var{place} more than once in a
|
|
single @code{cl-letf} form.
|
|
|
|
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{cl-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{cl-letf} is
|
|
to restore the original value of @var{place} afterwards.
|
|
@c I suspect this may no longer be true; either way it's
|
|
@c implementation detail and so not essential to document.
|
|
@ignore
|
|
(The redundant access-and-store suggested by the @code{(@var{place}
|
|
@var{place})} example does not actually occur.)
|
|
@end ignore
|
|
|
|
Note that in this case, and in fact almost every case, @var{place}
|
|
must have a well-defined value outside the @code{cl-letf} body.
|
|
There is essentially only one exception to this, which is @var{place}
|
|
a plain variable with a specified @var{value} (such as @code{(a 17)}
|
|
in the above example).
|
|
@c See https://debbugs.gnu.org/12758
|
|
@c Some or all of this was true for cl.el, but not for cl-lib.el.
|
|
@ignore
|
|
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 ignore
|
|
@end defmac
|
|
|
|
@defmac cl-letf* (bindings@dots{}) forms@dots{}
|
|
This macro is to @code{cl-letf} what @code{let*} is to @code{let}:
|
|
It does the bindings in sequential rather than parallel order.
|
|
@end defmac
|
|
|
|
@defmac cl-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{(cl-incf @var{place}
|
|
@var{n})} is the same as @code{(cl-callf + @var{place} @var{n})}.
|
|
Some more examples:
|
|
|
|
@example
|
|
(cl-callf abs my-number)
|
|
(cl-callf concat (buffer-name) "<" (number-to-string n) ">")
|
|
(cl-callf cl-union happy-people (list joe bob) :test 'same-person)
|
|
@end example
|
|
|
|
Note again that @code{cl-callf} is an extension to standard Common Lisp.
|
|
@end defmac
|
|
|
|
@defmac cl-callf2 @var{function} @var{arg1} @var{place} @var{args}@dots{}
|
|
This macro is like @code{cl-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{(cl-callf2 cons @var{x} @var{place})}.
|
|
@end defmac
|
|
|
|
The @code{cl-callf} and @code{cl-callf2} macros serve as building
|
|
blocks for other macros like @code{cl-incf}, and @code{cl-pushnew}.
|
|
The @code{cl-letf} and @code{cl-letf*} macros are used in the processing
|
|
of symbol macros; @pxref{Macro Bindings}.
|
|
|
|
@defmac with-memoization @var{place} @var{code}@dots{}
|
|
This macro provides a simple way to do memoization. @var{code} is
|
|
evaluated and then stashed in @var{place}. If @var{place}'s value is
|
|
non-@code{nil}, return that value instead of evaluating @var{code}.
|
|
@end defmac
|
|
|
|
|
|
@node Variable Bindings
|
|
@section Variable Bindings
|
|
@cindex variable binding
|
|
|
|
@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{cl-letf} and @code{cl-letf*} forms which
|
|
are also related to variable bindings.
|
|
|
|
@menu
|
|
* Dynamic Bindings:: The @code{cl-progv} form.
|
|
* Function Bindings:: @code{cl-flet} and @code{cl-labels}.
|
|
* Macro Bindings:: @code{cl-macrolet} and @code{cl-symbol-macrolet}.
|
|
@end menu
|
|
|
|
@node Dynamic Bindings
|
|
@subsection Dynamic Bindings
|
|
@cindex dynamic binding
|
|
|
|
@noindent
|
|
The standard @code{let} form binds variables whose names are known
|
|
at compile-time. The @code{cl-progv} form provides an easy way to
|
|
bind variables whose names are computed at run-time.
|
|
|
|
@defmac cl-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 bound to @code{nil}.
|
|
If @var{symbols} is shorter than @var{values}, the excess values
|
|
are ignored.
|
|
@end defmac
|
|
|
|
@node Function Bindings
|
|
@subsection Function Bindings
|
|
@cindex function binding
|
|
|
|
@noindent
|
|
These forms make @code{let}-like bindings to functions instead
|
|
of variables.
|
|
|
|
@defmac cl-flet (bindings@dots{}) forms@dots{}
|
|
This form establishes @code{let}-style bindings for functions rather
|
|
than values. Each @var{binding} must be a list of one of two forms:
|
|
either @w{@code{(@var{name} @var{expr})}} or @w{@code{(@var{name}
|
|
@var{arglist} @var{body}@dots{})}}. The @var{name} is the name of the
|
|
function, @var{expr} is an expression which returns the function value
|
|
to which the corresponding @var{name} should be bound, and
|
|
@var{arglist} and @var{body} are the argument list and the body of the
|
|
function to bind to @var{name}. Within @var{forms}, any reference to
|
|
the function @var{name} uses the local definition provided by
|
|
@var{bindings} instead of the global one.
|
|
|
|
A ``reference'' to a function name is either a call to that function,
|
|
or a use of its name quoted by @code{function} to be passed on to,
|
|
say, @code{mapcar}.
|
|
|
|
The bindings are lexical in scope. This means that all references to
|
|
the named functions must appear physically within @var{forms}.
|
|
|
|
Functions defined by @code{cl-flet} may use the full Common Lisp
|
|
argument notation supported by @code{cl-defun}; also, the function
|
|
body is enclosed in an implicit block as if by @code{cl-defun}.
|
|
@xref{Program Structure}.
|
|
|
|
Note that the @file{cl.el} version of this macro behaves slightly
|
|
differently. In particular, its binding is dynamic rather than
|
|
lexical. @xref{Obsolete Macros}.
|
|
@end defmac
|
|
|
|
@defmac cl-labels (bindings@dots{}) forms@dots{}
|
|
The @code{cl-labels} form is like @code{cl-flet}, except that
|
|
the function bindings can be recursive. The scoping is lexical,
|
|
but you can only capture functions in closures if
|
|
@code{lexical-binding} is @code{t}.
|
|
@xref{Closures,,,elisp,GNU Emacs Lisp Reference Manual}, and
|
|
@ref{Selecting Lisp Dialect,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
|
|
Lexical scoping means that all references to the named
|
|
functions must appear physically within the body of the
|
|
@code{cl-labels} form. References may appear both in the body
|
|
@var{forms} of @code{cl-labels} itself, and in the bodies of
|
|
the functions themselves. Thus, @code{cl-labels} can define
|
|
local recursive functions, or mutually-recursive sets of functions.
|
|
|
|
Note that the @file{cl.el} version of this macro behaves slightly
|
|
differently. @xref{Obsolete Macros}.
|
|
@end defmac
|
|
|
|
@node Macro Bindings
|
|
@subsection Macro Bindings
|
|
@cindex macro binding
|
|
|
|
@noindent
|
|
These forms create local macros and ``symbol macros''.
|
|
|
|
@defmac cl-macrolet (bindings@dots{}) forms@dots{}
|
|
This form is analogous to @code{cl-flet}, but for macros instead of
|
|
functions. Each @var{binding} is a list of the same form as the
|
|
arguments to @code{cl-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{cl-macrolet}.
|
|
|
|
Because of the nature of macros, @code{cl-macrolet} is always lexically
|
|
scoped. The @code{cl-macrolet} binding will
|
|
affect only calls that appear physically within the body
|
|
@var{forms}, possibly after expansion of other macros in the
|
|
body. Calls of @code{cl-macrolet} bound macros are expanded in the
|
|
global environment.
|
|
@end defmac
|
|
|
|
@defmac cl-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))
|
|
(cl-symbol-macrolet ((foo (car bar)))
|
|
(cl-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)}. A @code{let} (or @code{let*}, @code{lambda}, ...) binding of
|
|
the same symbol will locally shadow the symbol macro as is the case in
|
|
Common Lisp.
|
|
|
|
There is no analogue of @code{defmacro} for symbol macros; all symbol
|
|
macros are local. A typical use of @code{cl-symbol-macrolet} is in the
|
|
expansion of another macro:
|
|
|
|
@example
|
|
(cl-defmacro my-dolist ((x list) &rest body)
|
|
(let ((var (cl-gensym)))
|
|
(list 'cl-loop 'for var 'on list 'do
|
|
(cl-list* 'cl-symbol-macrolet
|
|
(list (list x (list 'car var)))
|
|
body))))
|
|
|
|
(setq mylist '(1 2 3 4))
|
|
(my-dolist (x mylist) (cl-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
|
|
(cl-loop for G1234 on mylist do
|
|
(cl-symbol-macrolet ((x (car G1234)))
|
|
(cl-incf x)))
|
|
@end example
|
|
|
|
@noindent
|
|
which in turn expands to
|
|
|
|
@example
|
|
(cl-loop for G1234 on mylist do (cl-incf (car G1234)))
|
|
@end example
|
|
|
|
@xref{Loop Facility}, for a description of the @code{cl-loop} macro.
|
|
This package defines a nonstandard @code{in-ref} loop clause that
|
|
works much like @code{my-dolist}.
|
|
@end defmac
|
|
|
|
@node Conditionals
|
|
@section Conditionals
|
|
@cindex conditionals
|
|
|
|
@noindent
|
|
These conditional forms augment Emacs Lisp's simple @code{if},
|
|
@code{and}, @code{or}, and @code{cond} forms.
|
|
|
|
@defmac cl-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{cl-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{cl-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
|
|
(cl-case (read-char)
|
|
(?a (do-a-thing))
|
|
(?b (do-b-thing))
|
|
((?\r ?\n) (do-ret-thing))
|
|
(t (do-other-thing)))
|
|
@end example
|
|
@end defmac
|
|
|
|
@defmac cl-ecase keyform clause@dots{}
|
|
This macro is just like @code{cl-case}, except that if the key does
|
|
not match any of the clauses, an error is signaled rather than
|
|
simply returning @code{nil}.
|
|
@end defmac
|
|
|
|
@defmac cl-typecase keyform clause@dots{}
|
|
This macro is a version of @code{cl-case} that checks for types
|
|
rather than values. Each @var{clause} is of the form
|
|
@samp{(@var{type} @var{body}@dots{})}. @xref{Type Predicates},
|
|
for a description of type specifiers. For example,
|
|
|
|
@example
|
|
(cl-typecase x
|
|
(integer (munch-integer x))
|
|
(float (munch-float x))
|
|
(string (munch-integer (string-to-number 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 @dots{})} type specifier.
|
|
@end defmac
|
|
|
|
@defmac cl-etypecase keyform clause@dots{}
|
|
This macro is just like @code{cl-typecase}, except that if the key does
|
|
not match any of the clauses, an error is signaled rather than
|
|
simply returning @code{nil}.
|
|
@end defmac
|
|
|
|
@node Blocks and Exits
|
|
@section Blocks and Exits
|
|
@cindex block
|
|
@cindex exit
|
|
|
|
@noindent
|
|
Common Lisp @dfn{blocks} provide a non-local exit mechanism very
|
|
similar to @code{catch} and @code{throw}, with lexical scoping.
|
|
This package actually implements @code{cl-block}
|
|
in terms of @code{catch}; however, the lexical scoping allows the
|
|
byte-compiler to omit the costly @code{catch} step if the
|
|
body of the block does not actually @code{cl-return-from} the block.
|
|
|
|
@defmac cl-block name forms@dots{}
|
|
The @var{forms} are evaluated as if by a @code{progn}. However,
|
|
if any of the @var{forms} execute @code{(cl-return-from @var{name})},
|
|
they will jump out and return directly from the @code{cl-block} form.
|
|
The @code{cl-block} returns the result of the last @var{form} unless
|
|
a @code{cl-return-from} occurs.
|
|
|
|
The @code{cl-block}/@code{cl-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) that evaluate to a tag at run-time; and
|
|
also that blocks are always lexically scoped.
|
|
In a dynamically scoped @code{catch}, functions called from the
|
|
@code{catch} body can also @code{throw} to the @code{catch}. This
|
|
is not an option for @code{cl-block}, where
|
|
the @code{cl-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{cl-defun} and @code{cl-defmacro}
|
|
forms, which do create the implicit block.
|
|
|
|
The Common Lisp looping constructs defined by this package,
|
|
such as @code{cl-loop} and @code{cl-dolist}, also create implicit blocks
|
|
just as in Common Lisp.
|
|
|
|
Because they are implemented in terms of Emacs Lisp's @code{catch}
|
|
and @code{throw}, blocks have the same overhead as actual
|
|
@code{catch} constructs (roughly two function calls). However,
|
|
the byte compiler will optimize away the @code{catch}
|
|
if the block does
|
|
not in fact contain any @code{cl-return} or @code{cl-return-from} calls
|
|
that jump to it. This means that @code{cl-do} loops and @code{cl-defun}
|
|
functions that don't use @code{cl-return} don't pay the overhead to
|
|
support it.
|
|
@end defmac
|
|
|
|
@defmac cl-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 defmac
|
|
|
|
@defmac cl-return [result]
|
|
This macro is exactly like @code{(cl-return-from nil @var{result})}.
|
|
Common Lisp loops like @code{cl-do} and @code{cl-dolist} implicitly enclose
|
|
themselves in @code{nil} blocks.
|
|
@end defmac
|
|
|
|
@c FIXME? Maybe this should be in a separate section?
|
|
@defmac cl-tagbody &rest labels-or-statements
|
|
This macro executes statements while allowing for control transfer to
|
|
user-defined labels. Each element of @var{labels-or-statements} can
|
|
be either a label (an integer or a symbol), or a cons-cell
|
|
(a statement). This distinction is made before macroexpansion.
|
|
Statements are executed in sequence, discarding any return value.
|
|
Any statement can transfer control at any time to the statements that follow
|
|
one of the labels with the special form @code{(go @var{label})}.
|
|
Labels have lexical scope and dynamic extent.
|
|
@end defmac
|
|
|
|
|
|
@node Iteration
|
|
@section Iteration
|
|
@cindex iteration
|
|
|
|
@noindent
|
|
The macros described here provide more sophisticated, high-level
|
|
looping constructs to complement Emacs Lisp's basic loop forms
|
|
(@pxref{Iteration,,,elisp,GNU Emacs Lisp Reference Manual}).
|
|
|
|
@defmac cl-loop forms@dots{}
|
|
This 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{cl-loop} is followed by zero or more Lisp expressions,
|
|
then @code{(cl-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
|
|
(cl-loop (foo) (if (no-more) (return 72)) (bar))
|
|
@end example
|
|
|
|
@noindent
|
|
is exactly equivalent to
|
|
|
|
@example
|
|
(cl-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 defmac
|
|
|
|
@defmac cl-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{cl-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{cl-do}.
|
|
|
|
The entire @code{cl-do} loop is enclosed in an implicit @code{nil}
|
|
block, so that you can use @code{(cl-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{cl-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 that 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{(cl-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
|
|
(cl-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 defmac
|
|
|
|
@defmac cl-do* (spec@dots{}) (end-test [result@dots{}]) forms@dots{}
|
|
This is to @code{cl-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{cl-psetq}.
|
|
|
|
Here is another way to write the above loop:
|
|
|
|
@example
|
|
(cl-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 defmac
|
|
|
|
@defmac cl-dolist (var list [result]) forms@dots{}
|
|
This is exactly like the standard Emacs Lisp macro @code{dolist},
|
|
but surrounds the loop with an implicit @code{nil} block.
|
|
@end defmac
|
|
|
|
@defmac cl-dotimes (var count [result]) forms@dots{}
|
|
This is exactly like the standard Emacs Lisp macro @code{dotimes},
|
|
but surrounds the loop with an implicit @code{nil} block.
|
|
The body is executed with @var{var} bound to the integers
|
|
from zero (inclusive) to @var{count} (exclusive), in turn. Then
|
|
@c FIXME lispref does not state this part explicitly, could move this there.
|
|
the @var{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. Use of @var{result} is deprecated.
|
|
@end defmac
|
|
|
|
@defmac cl-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 defmac
|
|
|
|
@defmac cl-do-all-symbols (var [result]) forms@dots{}
|
|
This is identical to @code{cl-do-symbols} except that the @var{obarray}
|
|
argument is omitted; it always iterates over the default obarray.
|
|
@end defmac
|
|
|
|
@xref{Mapping over Sequences}, for some more functions for
|
|
iterating over vectors or lists.
|
|
|
|
@node Loop Facility
|
|
@section Loop Facility
|
|
@cindex loop facility
|
|
|
|
@noindent
|
|
A common complaint with Lisp's traditional looping constructs was
|
|
that they were either too simple and limited, such as @code{dotimes}
|
|
or @code{while}, or too unreadable and obscure, like Common Lisp's
|
|
@code{do} loop.
|
|
|
|
To remedy this, Common Lisp added a construct called the ``Loop
|
|
Facility'' or ``@code{loop} macro'', with an easy-to-use but very
|
|
powerful and expressive syntax.
|
|
|
|
@menu
|
|
* Loop Basics:: The @code{cl-loop} macro, basic clause structure.
|
|
* Loop Examples:: Working examples of the @code{cl-loop} macro.
|
|
* For Clauses:: Clauses introduced by @code{for} or @code{as}.
|
|
* Iteration Clauses:: @code{repeat}, @code{while}, @code{thereis}, etc.
|
|
* Accumulation Clauses:: @code{collect}, @code{sum}, @code{maximize}, etc.
|
|
* Other Clauses:: @code{with}, @code{if}, @code{initially}, @code{finally}.
|
|
@end menu
|
|
|
|
@node Loop Basics
|
|
@subsection Loop Basics
|
|
|
|
@noindent
|
|
The @code{cl-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{cl-loop} is a macro, all parsing of the loop language
|
|
takes place at byte-compile time; compiled @code{cl-loop}s are just
|
|
as efficient as the equivalent @code{while} loops written longhand.
|
|
|
|
@defmac cl-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{cl-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{cl-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{cl-return} or @code{cl-return-from} to
|
|
break out of the loop.)
|
|
@end defmac
|
|
|
|
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 for additional discussion
|
|
and examples.
|
|
|
|
@node Loop Examples
|
|
@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{cl-loop}
|
|
language.
|
|
|
|
@example
|
|
(cl-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 @var{buf},
|
|
it calls @code{buffer-file-name} and collects the results into
|
|
a list, which is then returned from the @code{cl-loop} construct.
|
|
The result is a list of the file names of all the buffers in
|
|
Emacs's memory. The words @code{for}, @code{in}, and @code{collect}
|
|
are reserved words in the @code{cl-loop} language.
|
|
|
|
@example
|
|
(cl-loop repeat 20 do (insert "Yowsa\n"))
|
|
@end example
|
|
|
|
@noindent
|
|
This loop inserts the phrase ``Yowsa'' twenty times in the
|
|
current buffer.
|
|
|
|
@example
|
|
(cl-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
|
|
(cl-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
|
|
(cl-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{cl-loop} constructs if you want nested loops.
|
|
|
|
@node For Clauses
|
|
@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)
|
|
(cl-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
|
|
(cl-loop for x to 10 collect x)
|
|
@result{} (0 1 2 3 4 5 6 7 8 9 10)
|
|
(cl-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
|
|
(cl-loop for x in '(1 2 3 4 5 6) collect (* x x))
|
|
@result{} (1 4 9 16 25 36)
|
|
(cl-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
|
|
(cl-loop for x on '(1 2 3 4) collect x)
|
|
@result{} ((1 2 3 4) (2 3 4) (3 4) (4))
|
|
@end example
|
|
|
|
@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
|
|
(cl-loop for x in-ref my-list do (cl-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
|
|
(cl-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 @dots{})}
|
|
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
|
|
(cl-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{cl-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 @dots{} to}
|
|
or @code{while}.
|
|
|
|
@item for @var{var} being the hash-keys of @var{hash-table}
|
|
@itemx for @var{var} being the hash-values of @var{hash-table}
|
|
This clause iterates over the entries in @var{hash-table} with
|
|
@var{var} bound to each key, or value. A @samp{using} clause can bind
|
|
a second variable to the opposite part.
|
|
|
|
@example
|
|
(cl-loop for k being the hash-keys of h
|
|
using (hash-values v)
|
|
do
|
|
(message "key %S -> value %S" k v))
|
|
@end example
|
|
|
|
@item for @var{var} being the key-codes of @var{keymap}
|
|
@itemx for @var{var} being the key-bindings 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.
|
|
A @code{using} clause can access both the codes and the bindings
|
|
together.
|
|
|
|
@example
|
|
(cl-loop for c being the key-codes of (current-local-map)
|
|
using (key-bindings b)
|
|
do
|
|
(message "key %S -> binding %S" c b))
|
|
@end example
|
|
|
|
|
|
@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 @dots{})}
|
|
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{object}] @dots{}
|
|
This clause iterates over all intervals of a buffer or string 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. @xref{Text
|
|
Properties,,,elisp}.
|
|
|
|
@item for @var{var} being the frames
|
|
This clause iterates over all Emacs frames. 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}. It visits windows
|
|
in @code{next-window} order starting from @code{selected-window}
|
|
(or @code{frame-selected-window} if you specify @var{frame}).
|
|
This clause treats the minibuffer window in the same way as
|
|
@code{next-window} does. For greater flexibility, consider using
|
|
@code{walk-windows} instead.
|
|
|
|
@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
|
|
(cl-loop for x on my-list by 'cddr do @dots{})
|
|
(cl-loop for x = my-list then (cddr x) while x do @dots{})
|
|
@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
|
|
(cl-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{cl-psetq}).
|
|
|
|
@example
|
|
(cl-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))
|
|
(cl-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.
|
|
|
|
@cindex destructuring, in cl-loop
|
|
Another feature of the @code{cl-loop} macro is @emph{destructuring},
|
|
similar in concept to the destructuring provided by @code{defmacro}
|
|
(@pxref{Argument Lists}).
|
|
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
|
|
(cl-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, so for example
|
|
to process an alist
|
|
|
|
@example
|
|
(cl-loop for (key . value) in '((a . 1) (b . 2))
|
|
collect value)
|
|
@result{} (1 2)
|
|
@end example
|
|
|
|
@node Iteration Clauses
|
|
@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
|
|
(cl-loop repeat (1+ n) do @dots{})
|
|
(cl-loop for temp to n do @dots{})
|
|
@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{})
|
|
(cl-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 (cl-loop for size in size-list always (> size 10))
|
|
(only-big-sizes)
|
|
(some-small-sizes))
|
|
@end example
|
|
|
|
@item never @var{condition}
|
|
This clause is like @code{always}, except that the loop returns
|
|
@code{t} if all 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}.
|
|
|
|
@item iter-by @var{iterator}
|
|
This clause iterates over the values from the specified form, an
|
|
iterator object. See (@pxref{Generators,,,elisp,GNU Emacs Lisp
|
|
Reference Manual}).
|
|
@end table
|
|
|
|
@node Accumulation Clauses
|
|
@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
|
|
(cl-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
|
|
@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
|
|
(cl-loop with x = 17 do @dots{})
|
|
(let ((x 17)) (cl-loop do @dots{}))
|
|
(cl-loop for x = 17 then x do @dots{})
|
|
@end example
|
|
|
|
Naturally, the variable @var{var} might be used for some purpose
|
|
in the rest of the loop. For example:
|
|
|
|
@example
|
|
(cl-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)
|
|
(cl-loop for x below 10
|
|
if (cl-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)
|
|
(cl-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}@dots{}
|
|
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}@dots{}
|
|
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}@dots{}
|
|
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 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 (cl-return @var{form})} (or @code{cl-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{cl-loop},
|
|
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{cl-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 that
|
|
iterate over keymaps, overlays, intervals, frames, windows, and
|
|
buffers are Emacs-specific extensions.
|
|
|
|
@node Multiple Values
|
|
@section Multiple Values
|
|
@cindex 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{cl-compiler-macroexpand}) or return a list of values.
|
|
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{cl-values} form, for example, is a synonym for @code{list}
|
|
in Emacs.
|
|
|
|
@defmac cl-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 defmac
|
|
|
|
@defmac cl-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{cl-multiple-value-bind}.
|
|
@end defmac
|
|
|
|
Since a perfect emulation is not feasible in Emacs Lisp, this
|
|
package opts to keep it as simple and predictable as possible.
|
|
|
|
@node Macro-Writing Macros
|
|
@section Macro-Writing Macros
|
|
|
|
@noindent
|
|
This package includes two classic Common Lisp macro-writing macros to
|
|
help render complex macrology easier to read.
|
|
|
|
@defmac cl-with-gensyms names@dots{} body
|
|
This macro expands to code that executes @var{body} with each of the
|
|
variables in @var{names} bound to a fresh uninterned symbol, or
|
|
@dfn{gensym}, in Common Lisp parlance. For macros requiring more than
|
|
one gensym, use of @code{cl-with-gensyms} shortens the code and
|
|
renders one's intentions clearer. Compare:
|
|
|
|
@example
|
|
(defmacro my-macro (foo)
|
|
(let ((bar (gensym "bar"))
|
|
(baz (gensym "baz"))
|
|
(quux (gensym "quux")))
|
|
`(let ((,bar (+ @dots{})))
|
|
@dots{})))
|
|
|
|
(defmacro my-macro (foo)
|
|
(cl-with-gensyms (bar baz quux)
|
|
`(let ((,bar (+ @dots{})))
|
|
@dots{})))
|
|
@end example
|
|
@end defmac
|
|
|
|
@defmac cl-once-only ((variable form)@dots{}) body
|
|
This macro is primarily to help the macro programmer ensure that forms
|
|
supplied by the user of the macro are evaluated just once by its
|
|
expansion even though the result of evaluating the form is to occur
|
|
more than once. Less often, this macro is used to ensure that forms
|
|
supplied by the macro programmer are evaluated just once.
|
|
|
|
Each @var{variable} may be used to refer to the result of evaluating
|
|
@var{form} in @var{body}. @code{cl-once-only} binds each
|
|
@var{variable} to a fresh uninterned symbol during the evaluation of
|
|
@var{body}. Then, @code{cl-once-only} wraps the final expansion in
|
|
code to evaluate each @var{form} and bind the result to the
|
|
corresponding uninterned symbol. Thus, when the macro writer
|
|
substitutes the value for @var{variable} into the expansion they are
|
|
effectively referring to the result of evaluating @var{form}, rather
|
|
than @var{form} itself. Another way to put this is that each
|
|
@var{variable} is bound to an expression for the (singular) result of
|
|
evaluating @var{form}.
|
|
|
|
The most common case is where @var{variable} is one of the arguments
|
|
to the macro being written, so @code{(variable variable)} may be
|
|
abbreviated to just @code{variable}.
|
|
|
|
For example, consider this macro:
|
|
|
|
@example
|
|
(defmacro my-list (x y &rest forms)
|
|
(let ((x-result (gensym))
|
|
(y-result (gensym)))
|
|
`(let ((,x-result ,x)
|
|
(,y-result ,y))
|
|
(list ,x-result ,y-result ,x-result ,y-result
|
|
(progn ,@@forms))))
|
|
@end example
|
|
|
|
In a call like @w{@code{(my-list (pop foo) @dots{})}} the intermediate
|
|
binding to @code{x-result} ensures that the @code{pop} is not done
|
|
twice. But as a result the code is rather complex: the reader must
|
|
keep track of how @code{x-result} really just means the first
|
|
parameter of the call to the macro, and the required use of multiple
|
|
gensyms to avoid variable capture by @code{(progn ,@@forms)} obscures
|
|
things further. @code{cl-once-only} takes care of these details:
|
|
|
|
@example
|
|
(defmacro my-list (x y &rest forms)
|
|
(cl-once-only (x y)
|
|
`(list ,x ,y ,x ,y
|
|
(progn ,@@forms))))
|
|
@end example
|
|
@end defmac
|
|
|
|
@node Macros
|
|
@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:
|
|
|
|
@defmac cl-destructuring-bind arglist expr forms@dots{}
|
|
This macro expands to code that 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{cl-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 defmac
|
|
|
|
@cindex compiler macros
|
|
@cindex define compiler macros
|
|
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.
|
|
|
|
@defmac cl-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
|
|
(cl-define-compiler-macro cl-member (&whole form a list &rest keys)
|
|
(if (and (null keys)
|
|
(eq (car-safe a) 'quote)
|
|
(not (floatp (cadr a))))
|
|
(list 'memq a list)
|
|
form))
|
|
@end example
|
|
|
|
@noindent
|
|
This definition causes @code{(cl-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{cl-member} call is left intact. (The actual compiler macro
|
|
for @code{cl-member} optimizes a number of other cases, including
|
|
common @code{:test} predicates.)
|
|
@end defmac
|
|
|
|
@defun cl-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{cl-macrolet}
|
|
and @code{cl-symbol-macrolet} forms for making ``local'' macro
|
|
definitions.
|
|
|
|
@node Declarations
|
|
@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. For example, the byte-code system provides little
|
|
opportunity to benefit from type information.
|
|
@ignore
|
|
and @code{special} declarations are redundant in a fully
|
|
dynamically-scoped Lisp.
|
|
@end ignore
|
|
A few declarations are meaningful when byte compiler optimizations
|
|
are enabled, as they are by the default. Otherwise these
|
|
declarations will effectively be ignored.
|
|
|
|
@defun cl-proclaim decl-spec
|
|
This function records a ``global'' declaration specified by
|
|
@var{decl-spec}. Since @code{cl-proclaim} is a function, @var{decl-spec}
|
|
is evaluated and thus should normally be quoted.
|
|
@end defun
|
|
|
|
@defmac cl-declaim decl-specs@dots{}
|
|
This macro is like @code{cl-proclaim}, except that it takes any number
|
|
of @var{decl-spec} arguments, and the arguments are unevaluated and
|
|
unquoted. The @code{cl-declaim} macro also puts @code{(cl-eval-when
|
|
(compile load eval) @dots{})} 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{cl-declaim}
|
|
form.)
|
|
@end defmac
|
|
|
|
@defmac cl-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{cl-declare}
|
|
is @code{special}.
|
|
@end defmac
|
|
|
|
@defmac cl-locally declarations@dots{} forms@dots{}
|
|
In this package, @code{cl-locally} is no different from @code{progn}.
|
|
@end defmac
|
|
|
|
@defmac cl-the type form
|
|
@code{cl-the} returns the value of @code{form}, first checking (if
|
|
optimization settings permit) that it is of type @code{type}. Future
|
|
byte-compiler optimizations may also make use of this information to
|
|
improve runtime efficiency.
|
|
|
|
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 (cl-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 defmac
|
|
|
|
Each @var{decl-spec} in a @code{cl-proclaim}, @code{cl-declaim}, or
|
|
@code{cl-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
|
|
@c FIXME ?
|
|
Since all variables in Emacs Lisp are ``special'' (in the Common
|
|
Lisp sense), @code{special} declarations are only advisory. They
|
|
simply tell the 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{(cl-declare (special @var{var1} @var{var2}))} is
|
|
equivalent to @code{(defvar @var{var1}) (defvar @var{var2})}.
|
|
|
|
In top-level contexts, it is generally better to write
|
|
@code{(defvar @var{var})} than @code{(cl-declaim (special @var{var}))},
|
|
since @code{defvar} makes your intentions clearer.
|
|
|
|
@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 function @code{cl-acons} is declared @code{inline}
|
|
by this package so that the form @code{(cl-acons @var{key} @var{value}
|
|
@var{alist})} will
|
|
expand directly into @code{(cons (cons @var{key} @var{value}) @var{alist})}
|
|
when it is called in user functions, so as to save function calls.
|
|
|
|
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
|
|
(cl-declaim (inline foo bar))
|
|
(cl-eval-when (compile load eval)
|
|
(cl-proclaim '(inline foo bar)))
|
|
(defsubst foo (@dots{}) @dots{}) ; 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{(cl-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.
|
|
|
|
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, the @code{speed} quality is tied to the @code{byte-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{nil} for @code{(safety 3)} and to @code{t} 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{cl-proclaim} or @code{cl-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 byte-compiler. (The @code{cl-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. 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 of the variable @code{byte-compile-warnings}
|
|
for more details.
|
|
@end table
|
|
|
|
@node Symbols
|
|
@chapter Symbols
|
|
|
|
@noindent
|
|
This package defines several symbol-related features that were
|
|
missing from Emacs Lisp.
|
|
|
|
@menu
|
|
* Property Lists:: @code{cl-get}, @code{cl-remprop}, @code{cl-getf}, @code{cl-remf}.
|
|
* Creating Symbols:: @code{cl-gensym}, @code{cl-gentemp}.
|
|
@end menu
|
|
|
|
@node Property Lists
|
|
@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 cl-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{cl-get} is equivalent to Common
|
|
Lisp's @code{get}.)
|
|
|
|
The @code{cl-get} function is @code{setf}-able; when used in this
|
|
fashion, the @var{default} argument is allowed but ignored.
|
|
@end defun
|
|
|
|
@defun cl-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{cl-remprop} for most purposes.)
|
|
@end defun
|
|
|
|
@defun cl-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{} (cl-getf (symbol-plist sym) prop)
|
|
@end example
|
|
|
|
It is valid to use @code{cl-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 (cl-getf (symbol-plist sym) prop) val)
|
|
@end example
|
|
|
|
The @code{get} and @code{cl-get} functions are also @code{setf}-able.
|
|
The fact that @code{default} is ignored can sometimes be useful:
|
|
|
|
@example
|
|
(cl-incf (cl-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{cl-getf} is just a regular
|
|
function and its @var{place} argument can actually be any Lisp
|
|
expression.
|
|
@end defun
|
|
|
|
@defmac cl-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 defmac
|
|
|
|
@node Creating Symbols
|
|
@section Creating Symbols
|
|
@cindex gensym
|
|
|
|
@noindent
|
|
These functions create unique symbols, typically for use as
|
|
temporary variables.
|
|
|
|
@defun cl-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.
|
|
|
|
(Internally, the variable @code{cl--gensym-counter} holds the counter
|
|
used to generate names. It is initialized with zero and incremented
|
|
after each use.)
|
|
@end defun
|
|
|
|
@defun cl-gentemp &optional x
|
|
This function is like @code{cl-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
|
|
|
|
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 related function
|
|
@code{defkeyword} (to create self-quoting keyword symbols) is not
|
|
provided.
|
|
|
|
@node Numbers
|
|
@chapter Numbers
|
|
|
|
@noindent
|
|
This section defines a few simple Common Lisp operations on numbers
|
|
that were left out of Emacs Lisp.
|
|
|
|
@menu
|
|
* Predicates on Numbers:: @code{cl-plusp}, @code{cl-oddp}, etc.
|
|
* Numerical Functions:: @code{cl-floor}, @code{cl-ceiling}, etc.
|
|
* Random Numbers:: @code{cl-random}, @code{cl-make-random-state}.
|
|
* Implementation Parameters:: @code{cl-most-positive-float}, etc.
|
|
@end menu
|
|
|
|
@node Predicates on 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 cl-plusp number
|
|
This predicate tests whether @var{number} is positive. It is an
|
|
error if the argument is not a number.
|
|
@end defun
|
|
|
|
@defun cl-minusp number
|
|
This predicate tests whether @var{number} is negative. It is an
|
|
error if the argument is not a number.
|
|
@end defun
|
|
|
|
@defun cl-oddp integer
|
|
This predicate tests whether @var{integer} is odd. It is an
|
|
error if the argument is not an integer.
|
|
@end defun
|
|
|
|
@defun cl-evenp integer
|
|
This predicate tests whether @var{integer} is even. It is an
|
|
error if the argument is not an integer.
|
|
@end defun
|
|
|
|
@defun cl-digit-char-p char radix
|
|
Test if @var{char} is a digit in the specified @var{radix} (default is
|
|
10). If it is, return the numerical value of digit @var{char} in
|
|
@var{radix}.
|
|
@end defun
|
|
|
|
@node Numerical Functions
|
|
@section Numerical Functions
|
|
|
|
@noindent
|
|
These functions perform various arithmetic operations on numbers.
|
|
|
|
@defun cl-gcd &rest integers
|
|
This function returns the Greatest Common Divisor of the arguments.
|
|
For one argument, it returns the absolute value of that argument.
|
|
For zero arguments, it returns zero.
|
|
@end defun
|
|
|
|
@defun cl-lcm &rest integers
|
|
This function returns the Least Common Multiple of the arguments.
|
|
For one argument, it returns the absolute value of that argument.
|
|
For zero arguments, it returns one.
|
|
@end defun
|
|
|
|
@defun cl-isqrt integer
|
|
This function computes the ``integer square root'' of its integer
|
|
argument, i.e., the greatest integer less than or equal to the true
|
|
square root of the argument.
|
|
@end defun
|
|
|
|
@defun cl-floor number &optional divisor
|
|
With one argument, @code{cl-floor} returns a list of two numbers:
|
|
The argument rounded down (toward minus infinity) to an integer,
|
|
and the ``remainder'' which would have to be added back to the
|
|
first return value to yield the argument again. If the argument
|
|
is an integer @var{x}, the result is always the list @code{(@var{x} 0)}.
|
|
If the argument is a floating-point number, the first
|
|
result is a Lisp integer and the second is a Lisp float between
|
|
0 (inclusive) and 1 (exclusive).
|
|
|
|
With two arguments, @code{cl-floor} divides @var{number} by
|
|
@var{divisor}, and returns the floor of the quotient and the
|
|
corresponding remainder as a list of two numbers. If
|
|
@code{(cl-floor @var{x} @var{y})} returns @code{(@var{q} @var{r})},
|
|
then @code{@var{q}*@var{y} + @var{r} = @var{x}}, with @var{r}
|
|
between 0 (inclusive) and @var{r} (exclusive). Also, note
|
|
that @code{(cl-floor @var{x})} is exactly equivalent to
|
|
@code{(cl-floor @var{x} 1)}.
|
|
|
|
This function is entirely compatible with Common Lisp's @code{floor}
|
|
function, except that it returns the two results in a list since
|
|
Emacs Lisp does not support multiple-valued functions.
|
|
@end defun
|
|
|
|
@defun cl-ceiling number &optional divisor
|
|
This function implements the Common Lisp @code{ceiling} function,
|
|
which is analogous to @code{floor} except that it rounds the
|
|
argument or quotient of the arguments up toward plus infinity.
|
|
The remainder will be between 0 and minus @var{r}.
|
|
@end defun
|
|
|
|
@defun cl-truncate number &optional divisor
|
|
This function implements the Common Lisp @code{truncate} function,
|
|
which is analogous to @code{floor} except that it rounds the
|
|
argument or quotient of the arguments toward zero. Thus it is
|
|
equivalent to @code{cl-floor} if the argument or quotient is
|
|
positive, or to @code{cl-ceiling} otherwise. The remainder has
|
|
the same sign as @var{number}.
|
|
@end defun
|
|
|
|
@defun cl-round number &optional divisor
|
|
This function implements the Common Lisp @code{round} function,
|
|
which is analogous to @code{floor} except that it rounds the
|
|
argument or quotient of the arguments to the nearest integer.
|
|
In the case of a tie (the argument or quotient is exactly
|
|
halfway between two integers), it rounds to the even integer.
|
|
@end defun
|
|
|
|
@defun cl-mod number divisor
|
|
This function returns the same value as the second return value
|
|
of @code{cl-floor}.
|
|
@end defun
|
|
|
|
@defun cl-rem number divisor
|
|
This function returns the same value as the second return value
|
|
of @code{cl-truncate}.
|
|
@end defun
|
|
|
|
@defun cl-parse-integer string &key start end radix junk-allowed
|
|
This function implements the Common Lisp @code{parse-integer}
|
|
function. It parses an integer in the specified @var{radix} from the
|
|
substring of @var{string} between @var{start} and @var{end}. Any
|
|
leading and trailing whitespace chars are ignored. The function
|
|
signals an error if the substring between @var{start} and @var{end}
|
|
cannot be parsed as an integer, unless @var{junk-allowed} is
|
|
non-@code{nil}.
|
|
@end defun
|
|
|
|
@node Random Numbers
|
|
@section Random Numbers
|
|
|
|
@noindent
|
|
This package also provides an implementation of the Common Lisp
|
|
random number generator. It uses its own additive-congruential
|
|
algorithm, which is much more likely to give statistically clean
|
|
@c FIXME? Still true?
|
|
random numbers than the simple generators supplied by many
|
|
operating systems.
|
|
|
|
@defun cl-random number &optional state
|
|
This function returns a random nonnegative number less than
|
|
@var{number}, and of the same type (either integer or floating-point).
|
|
The @var{state} argument should be a @code{random-state} object
|
|
that holds the state of the random number generator. The
|
|
function modifies this state object as a side effect. If
|
|
@var{state} is omitted, it defaults to the internal variable
|
|
@code{cl--random-state}, which contains a pre-initialized
|
|
default @code{random-state} object. (Since any number of programs in
|
|
the Emacs process may be accessing @code{cl--random-state} in
|
|
interleaved fashion, the sequence generated from this will be
|
|
irreproducible for all intents and purposes.)
|
|
@end defun
|
|
|
|
@defun cl-make-random-state &optional state
|
|
This function creates or copies a @code{random-state} object.
|
|
If @var{state} is omitted or @code{nil}, it returns a new copy of
|
|
@code{cl--random-state}. This is a copy in the sense that future
|
|
sequences of calls to @code{(cl-random @var{n})} and
|
|
@code{(cl-random @var{n} @var{s})} (where @var{s} is the new
|
|
random-state object) will return identical sequences of random
|
|
numbers.
|
|
|
|
If @var{state} is a @code{random-state} object, this function
|
|
returns a copy of that object. If @var{state} is @code{t}, this
|
|
function returns a new @code{random-state} object seeded from the
|
|
date and time. As an extension to Common Lisp, @var{state} may also
|
|
be an integer in which case the new object is seeded from that
|
|
integer; each different integer seed will result in a completely
|
|
different sequence of random numbers.
|
|
|
|
It is valid to print a @code{random-state} object to a buffer or
|
|
file and later read it back with @code{read}. If a program wishes
|
|
to use a sequence of pseudo-random numbers which can be reproduced
|
|
later for debugging, it can call @code{(cl-make-random-state t)} to
|
|
get a new sequence, then print this sequence to a file. When the
|
|
program is later rerun, it can read the original run's random-state
|
|
from the file.
|
|
@end defun
|
|
|
|
@defun cl-random-state-p object
|
|
This predicate returns @code{t} if @var{object} is a
|
|
@code{random-state} object, or @code{nil} otherwise.
|
|
@end defun
|
|
|
|
@node Implementation Parameters
|
|
@section Implementation Parameters
|
|
|
|
@noindent
|
|
This package defines several useful constants having to do with
|
|
floating-point numbers.
|
|
|
|
It determines their values by exercising the computer's
|
|
floating-point arithmetic in various ways. Because this operation
|
|
might be slow, the code for initializing them is kept in a separate
|
|
function that must be called before the parameters can be used.
|
|
|
|
@defun cl-float-limits
|
|
This function makes sure that the Common Lisp floating-point parameters
|
|
like @code{cl-most-positive-float} have been initialized. Until it is
|
|
called, these parameters have unspecified values.
|
|
If the parameters have already been initialized, the function returns
|
|
immediately.
|
|
@end defun
|
|
|
|
Since true Common Lisp supports up to four different kinds of floating-point
|
|
numbers, it has families of constants like
|
|
@code{most-positive-single-float}, @code{most-positive-double-float},
|
|
@code{most-positive-long-float}, and so on. This package uses just
|
|
one set of constants because Emacs has only one kind of
|
|
floating-point number, namely the IEEE binary64 floating-point format.
|
|
@xref{Float Basics,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
|
|
@defvar cl-most-positive-float
|
|
This constant equals the largest finite value a Lisp float can hold.
|
|
For IEEE binary64 format, this equals @code{(- (expt 2 1024) (expt 2
|
|
971))}, which equals @code{1.7976931348623157e+308}.
|
|
@end defvar
|
|
|
|
@defvar cl-most-negative-float
|
|
This constant equals the most negative finite value a Lisp float can hold.
|
|
For IEEE binary64 format, this equals @code{(- cl-most-positive-float)}.
|
|
@end defvar
|
|
|
|
@defvar cl-least-positive-normalized-float
|
|
This constant equals the smallest positive Lisp float that is
|
|
@dfn{normalized}, i.e., that has full precision.
|
|
For IEEE binary64 format, this equals @code{(expt 2 -1022)},
|
|
which equals @code{2.2250738585072014e-308}.
|
|
@end defvar
|
|
|
|
@defvar cl-least-positive-float
|
|
This constant equals the smallest Lisp float value greater than zero.
|
|
For IEEE binary64 format, this equals @code{5e-324} (which equals
|
|
@code{(expt 2 -1074)}) if subnormal numbers are supported, and
|
|
@code{cl-least-positive-normalized-float} otherwise.
|
|
@end defvar
|
|
|
|
@defvar cl-least-negative-float
|
|
This constant is the negative counterpart of @code{cl-least-positive-float}.
|
|
@end defvar
|
|
|
|
@defvar cl-least-negative-normalized-float
|
|
This constant is the negative counterpart of
|
|
@code{cl-least-positive-normalized-float}.
|
|
@end defvar
|
|
|
|
@defvar cl-float-epsilon
|
|
This constant is the smallest positive Lisp float that can be added
|
|
to 1.0 to produce a distinct value. Adding a smaller number to 1.0
|
|
will yield 1.0 again due to roundoff. For IEEE binary64 format, this
|
|
equals @code{(expt 2 -52)}, which equals @code{2.220446049250313e-16}.
|
|
@end defvar
|
|
|
|
@defvar cl-float-negative-epsilon
|
|
This is the smallest positive value that can be subtracted from
|
|
1.0 to produce a distinct value. For IEEE binary64 format, this
|
|
equals @code{(expt 2 -53)}, which equals @code{1.1102230246251565e-16}.
|
|
@end defvar
|
|
|
|
@node Sequences
|
|
@chapter Sequences
|
|
|
|
@noindent
|
|
Common Lisp defines a number of functions that operate on
|
|
@dfn{sequences}, which are either lists, strings, or vectors.
|
|
Emacs Lisp includes a few of these, notably @code{elt} and
|
|
@code{length}; this package defines most of the rest.
|
|
|
|
@menu
|
|
* Sequence Basics:: Arguments shared by all sequence functions.
|
|
* Mapping over Sequences:: @code{cl-mapcar}, @code{cl-map}, @code{cl-maplist}, etc.
|
|
* Sequence Functions:: @code{cl-subseq}, @code{cl-remove}, @code{cl-substitute}, etc.
|
|
* Searching Sequences:: @code{cl-find}, @code{cl-count}, @code{cl-search}, etc.
|
|
* Sorting Sequences:: @code{cl-sort}, @code{cl-stable-sort}, @code{cl-merge}.
|
|
@end menu
|
|
|
|
@node Sequence Basics
|
|
@section Sequence Basics
|
|
|
|
@noindent
|
|
Many of the sequence functions take keyword arguments; @pxref{Argument
|
|
Lists}. All keyword arguments are optional and, if specified,
|
|
may appear in any order.
|
|
|
|
The @code{:key} argument should be passed either @code{nil}, or a
|
|
function of one argument. This key function is used as a filter
|
|
through which the elements of the sequence are seen; for example,
|
|
@code{(cl-find x y :key 'car)} is similar to @code{(cl-assoc x y)}.
|
|
It searches for an element of the list whose @sc{car} equals
|
|
@code{x}, rather than for an element which equals @code{x} itself.
|
|
If @code{:key} is omitted or @code{nil}, the filter is effectively
|
|
the identity function.
|
|
|
|
The @code{:test} and @code{:test-not} arguments should be either
|
|
@code{nil}, or functions of two arguments. The test function is
|
|
used to compare two sequence elements, or to compare a search value
|
|
with sequence elements. (The two values are passed to the test
|
|
function in the same order as the original sequence function
|
|
arguments from which they are derived, or, if they both come from
|
|
the same sequence, in the same order as they appear in that sequence.)
|
|
The @code{:test} argument specifies a function which must return
|
|
true (non-@code{nil}) to indicate a match; instead, you may use
|
|
@code{:test-not} to give a function which returns @emph{false} to
|
|
indicate a match. The default test function is @code{eql}.
|
|
|
|
Many functions that take @var{item} and @code{:test} or @code{:test-not}
|
|
arguments also come in @code{-if} and @code{-if-not} varieties,
|
|
where a @var{predicate} function is passed instead of @var{item},
|
|
and sequence elements match if the predicate returns true on them
|
|
(or false in the case of @code{-if-not}). For example:
|
|
|
|
@example
|
|
(cl-remove 0 seq :test '=) @equiv{} (cl-remove-if 'zerop seq)
|
|
@end example
|
|
|
|
@noindent
|
|
to remove all zeros from sequence @code{seq}.
|
|
|
|
Some operations can work on a subsequence of the argument sequence;
|
|
these function take @code{:start} and @code{:end} arguments, which
|
|
default to zero and the length of the sequence, respectively.
|
|
Only elements between @var{start} (inclusive) and @var{end}
|
|
(exclusive) are affected by the operation. The @var{end} argument
|
|
may be passed @code{nil} to signify the length of the sequence;
|
|
otherwise, both @var{start} and @var{end} must be integers, with
|
|
@code{0 <= @var{start} <= @var{end} <= (length @var{seq})}.
|
|
If the function takes two sequence arguments, the limits are
|
|
defined by keywords @code{:start1} and @code{:end1} for the first,
|
|
and @code{:start2} and @code{:end2} for the second.
|
|
|
|
A few functions accept a @code{:from-end} argument, which, if
|
|
non-@code{nil}, causes the operation to go from right-to-left
|
|
through the sequence instead of left-to-right, and a @code{:count}
|
|
argument, which specifies an integer maximum number of elements
|
|
to be removed or otherwise processed.
|
|
|
|
The sequence functions make no guarantees about the order in
|
|
which the @code{:test}, @code{:test-not}, and @code{:key} functions
|
|
are called on various elements. Therefore, it is a bad idea to depend
|
|
on side effects of these functions. For example, @code{:from-end}
|
|
may cause the sequence to be scanned actually in reverse, or it may
|
|
be scanned forwards but computing a result ``as if'' it were scanned
|
|
backwards. (Some functions, like @code{cl-mapcar} and @code{cl-every},
|
|
@emph{do} specify exactly the order in which the function is called
|
|
so side effects are perfectly acceptable in those cases.)
|
|
|
|
Strings may contain ``text properties'' as well
|
|
as character data. Except as noted, it is undefined whether or
|
|
not text properties are preserved by sequence functions. For
|
|
example, @code{(cl-remove ?A @var{str})} may or may not preserve
|
|
the properties of the characters copied from @var{str} into the
|
|
result.
|
|
|
|
@node Mapping over Sequences
|
|
@section Mapping over Sequences
|
|
|
|
@noindent
|
|
These functions ``map'' the function you specify over the elements
|
|
of lists or arrays. They are all variations on the theme of the
|
|
built-in function @code{mapcar}.
|
|
|
|
@defun cl-mapcar function seq &rest more-seqs
|
|
This function calls @var{function} on successive parallel sets of
|
|
elements from its argument sequences. Given a single @var{seq}
|
|
argument it is equivalent to @code{mapcar}; given @var{n} sequences,
|
|
it calls the function with the first elements of each of the sequences
|
|
as the @var{n} arguments to yield the first element of the result
|
|
list, then with the second elements, and so on. The mapping stops as
|
|
soon as the shortest sequence runs out. The argument sequences may
|
|
be any mixture of lists, strings, and vectors; the return sequence
|
|
is always a list.
|
|
|
|
Common Lisp's @code{mapcar} accepts multiple arguments but works
|
|
only on lists; Emacs Lisp's @code{mapcar} accepts a single sequence
|
|
argument. This package's @code{cl-mapcar} works as a compatible
|
|
superset of both.
|
|
@end defun
|
|
|
|
@defun cl-map result-type function seq &rest more-seqs
|
|
This function maps @var{function} over the argument sequences,
|
|
just like @code{cl-mapcar}, but it returns a sequence of type
|
|
@var{result-type} rather than a list. @var{result-type} must
|
|
be one of the following symbols: @code{vector}, @code{string},
|
|
@code{list} (in which case the effect is the same as for
|
|
@code{cl-mapcar}), or @code{nil} (in which case the results are
|
|
thrown away and @code{cl-map} returns @code{nil}).
|
|
@end defun
|
|
|
|
@defun cl-maplist function list &rest more-lists
|
|
This function calls @var{function} on each of its argument lists,
|
|
then on the @sc{cdr}s of those lists, and so on, until the
|
|
shortest list runs out. The results are returned in the form
|
|
of a list. Thus, @code{cl-maplist} is like @code{cl-mapcar} except
|
|
that it passes in the list pointers themselves rather than the
|
|
@sc{car}s of the advancing pointers.
|
|
@end defun
|
|
|
|
@defun cl-mapc function seq &rest more-seqs
|
|
This function is like @code{cl-mapcar}, except that the values returned
|
|
by @var{function} are ignored and thrown away rather than being
|
|
collected into a list. The return value of @code{cl-mapc} is @var{seq},
|
|
the first sequence. This function is more general than the Emacs
|
|
primitive @code{mapc}. (Note that this function is called
|
|
@code{cl-mapc} even in @file{cl.el}, rather than @code{mapc*} as you
|
|
might expect.)
|
|
@c https://debbugs.gnu.org/6575
|
|
@end defun
|
|
|
|
@defun cl-mapl function list &rest more-lists
|
|
This function is like @code{cl-maplist}, except that it throws away
|
|
the values returned by @var{function}.
|
|
@end defun
|
|
|
|
@defun cl-mapcan function seq &rest more-seqs
|
|
This function is like @code{cl-mapcar}, except that it concatenates
|
|
the return values (which must be lists) using @code{nconc},
|
|
rather than simply collecting them into a list.
|
|
@end defun
|
|
|
|
@defun cl-mapcon function list &rest more-lists
|
|
This function is like @code{cl-maplist}, except that it concatenates
|
|
the return values using @code{nconc}.
|
|
@end defun
|
|
|
|
@defun cl-some predicate seq &rest more-seqs
|
|
This function calls @var{predicate} on each element of @var{seq}
|
|
in turn; if @var{predicate} returns a non-@code{nil} value,
|
|
@code{cl-some} returns that value, otherwise it returns @code{nil}.
|
|
Given several sequence arguments, it steps through the sequences
|
|
in parallel until the shortest one runs out, just as in
|
|
@code{cl-mapcar}. You can rely on the left-to-right order in which
|
|
the elements are visited, and on the fact that mapping stops
|
|
immediately as soon as @var{predicate} returns non-@code{nil}.
|
|
@end defun
|
|
|
|
@defun cl-every predicate seq &rest more-seqs
|
|
This function calls @var{predicate} on each element of the sequence(s)
|
|
in turn; it returns @code{nil} as soon as @var{predicate} returns
|
|
@code{nil} for any element, or @code{t} if the predicate was true
|
|
for all elements.
|
|
@end defun
|
|
|
|
@defun cl-notany predicate seq &rest more-seqs
|
|
This function calls @var{predicate} on each element of the sequence(s)
|
|
in turn; it returns @code{nil} as soon as @var{predicate} returns
|
|
a non-@code{nil} value for any element, or @code{t} if the predicate
|
|
was @code{nil} for all elements.
|
|
@end defun
|
|
|
|
@defun cl-notevery predicate seq &rest more-seqs
|
|
This function calls @var{predicate} on each element of the sequence(s)
|
|
in turn; it returns a non-@code{nil} value as soon as @var{predicate}
|
|
returns @code{nil} for any element, or @code{nil} if the predicate was
|
|
true for all elements.
|
|
@end defun
|
|
|
|
@defun cl-reduce function seq @t{&key :from-end :start :end :initial-value :key}
|
|
This function returns the result of calling @var{function} on the
|
|
first and second elements of @var{seq}, then calling @var{function}
|
|
with that result and the third element of @var{seq}, then with that
|
|
result and the fourth element of @var{seq}, etc.
|
|
|
|
Here is an example. Suppose @var{function} is @code{*} and @var{seq}
|
|
is the list @code{(2 3 4 5)}. The first two elements of the list are
|
|
combined with @code{(* 2 3) = 6}; this is combined with the next
|
|
element, @code{(* 6 4) = 24}, and that is combined with the final
|
|
element: @code{(* 24 5) = 120}. Note that the @code{*} function happens
|
|
to be self-reducing, so that @code{(* 2 3 4 5)} has the same effect as
|
|
an explicit call to @code{cl-reduce}.
|
|
|
|
If @code{:from-end} is true, the reduction is right-associative instead
|
|
of left-associative:
|
|
|
|
@example
|
|
(cl-reduce '- '(1 2 3 4))
|
|
@equiv{} (- (- (- 1 2) 3) 4) @result{} -8
|
|
(cl-reduce '- '(1 2 3 4) :from-end t)
|
|
@equiv{} (- 1 (- 2 (- 3 4))) @result{} -2
|
|
@end example
|
|
|
|
If @code{:key} is specified, it is a function of one argument, which
|
|
is called on each of the sequence elements in turn.
|
|
|
|
If @code{:initial-value} is specified, it is effectively added to the
|
|
front (or rear in the case of @code{:from-end}) of the sequence.
|
|
The @code{:key} function is @emph{not} applied to the initial value.
|
|
|
|
If the sequence, including the initial value, has exactly one element
|
|
then that element is returned without ever calling @var{function}.
|
|
If the sequence is empty (and there is no initial value), then
|
|
@var{function} is called with no arguments to obtain the return value.
|
|
@end defun
|
|
|
|
All of these mapping operations can be expressed conveniently in
|
|
terms of the @code{cl-loop} macro. In compiled code, @code{cl-loop} will
|
|
be faster since it generates the loop as in-line code with no
|
|
function calls.
|
|
|
|
@node Sequence Functions
|
|
@section Sequence Functions
|
|
|
|
@noindent
|
|
This section describes a number of Common Lisp functions for
|
|
operating on sequences.
|
|
|
|
@defun cl-subseq sequence start &optional end
|
|
This function returns a given subsequence of the argument
|
|
@var{sequence}, which may be a list, string, or vector.
|
|
The indices @var{start} and @var{end} must be in range, and
|
|
@var{start} must be no greater than @var{end}. If @var{end}
|
|
is omitted, it defaults to the length of the sequence. The
|
|
return value is always a copy; it does not share structure
|
|
with @var{sequence}.
|
|
|
|
As an extension to Common Lisp, @var{start} and/or @var{end}
|
|
may be negative, in which case they represent a distance back
|
|
from the end of the sequence. This is for compatibility with
|
|
Emacs's @code{substring} function. Note that @code{cl-subseq} is
|
|
the @emph{only} sequence function that allows negative
|
|
@var{start} and @var{end}.
|
|
|
|
You can use @code{setf} on a @code{cl-subseq} form to replace a
|
|
specified range of elements with elements from another sequence.
|
|
The replacement is done as if by @code{cl-replace}, described below.
|
|
@end defun
|
|
|
|
@defun cl-concatenate result-type &rest seqs
|
|
This function concatenates the argument sequences together to
|
|
form a result sequence of type @var{result-type}, one of the
|
|
symbols @code{vector}, @code{string}, or @code{list}. The
|
|
arguments are always copied, even in cases such as
|
|
@code{(cl-concatenate 'list '(1 2 3))} where the result is
|
|
identical to an argument.
|
|
@end defun
|
|
|
|
@defun cl-fill seq item @t{&key :start :end}
|
|
This function fills the elements of the sequence (or the specified
|
|
part of the sequence) with the value @var{item}.
|
|
@end defun
|
|
|
|
@defun cl-replace seq1 seq2 @t{&key :start1 :end1 :start2 :end2}
|
|
This function copies part of @var{seq2} into part of @var{seq1}.
|
|
The sequence @var{seq1} is not stretched or resized; the amount
|
|
of data copied is simply the shorter of the source and destination
|
|
(sub)sequences. The function returns @var{seq1}.
|
|
|
|
If @var{seq1} and @var{seq2} are @code{eq}, then the replacement
|
|
will work correctly even if the regions indicated by the start
|
|
and end arguments overlap. However, if @var{seq1} and @var{seq2}
|
|
are lists that share storage but are not @code{eq}, and the
|
|
start and end arguments specify overlapping regions, the effect
|
|
is undefined.
|
|
@end defun
|
|
|
|
@defun cl-remove item seq @t{&key :test :test-not :key :count :start :end :from-end}
|
|
This returns a copy of @var{seq} with all elements matching
|
|
@var{item} removed. The result may share storage with or be
|
|
@code{eq} to @var{seq} in some circumstances, but the original
|
|
@var{seq} will not be modified. The @code{:test}, @code{:test-not},
|
|
and @code{:key} arguments define the matching test that is used;
|
|
by default, elements @code{eql} to @var{item} are removed. The
|
|
@code{:count} argument specifies the maximum number of matching
|
|
elements that can be removed (only the leftmost @var{count} matches
|
|
are removed). The @code{:start} and @code{:end} arguments specify
|
|
a region in @var{seq} in which elements will be removed; elements
|
|
outside that region are not matched or removed. The @code{:from-end}
|
|
argument, if true, says that elements should be deleted from the
|
|
end of the sequence rather than the beginning (this matters only
|
|
if @var{count} was also specified).
|
|
@end defun
|
|
|
|
@defun cl-delete item seq @t{&key :test :test-not :key :count :start :end :from-end}
|
|
This deletes all elements of @var{seq} that match @var{item}.
|
|
It is a destructive operation. Since Emacs Lisp does not support
|
|
stretchable strings or vectors, this is the same as @code{cl-remove}
|
|
for those sequence types. On lists, @code{cl-remove} will copy the
|
|
list if necessary to preserve the original list, whereas
|
|
@code{cl-delete} will splice out parts of the argument list.
|
|
Compare @code{append} and @code{nconc}, which are analogous
|
|
non-destructive and destructive list operations in Emacs Lisp.
|
|
@end defun
|
|
|
|
@findex cl-remove-if
|
|
@findex cl-remove-if-not
|
|
@findex cl-delete-if
|
|
@findex cl-delete-if-not
|
|
The predicate-oriented functions @code{cl-remove-if}, @code{cl-remove-if-not},
|
|
@code{cl-delete-if}, and @code{cl-delete-if-not} are defined similarly.
|
|
|
|
@defun cl-remove-duplicates seq @t{&key :test :test-not :key :start :end :from-end}
|
|
This function returns a copy of @var{seq} with duplicate elements
|
|
removed. Specifically, if two elements from the sequence match
|
|
according to the @code{:test}, @code{:test-not}, and @code{:key}
|
|
arguments, only the rightmost one is retained. If @code{:from-end}
|
|
is true, the leftmost one is retained instead. If @code{:start} or
|
|
@code{:end} is specified, only elements within that subsequence are
|
|
examined or removed.
|
|
@end defun
|
|
|
|
@defun cl-delete-duplicates seq @t{&key :test :test-not :key :start :end :from-end}
|
|
This function deletes duplicate elements from @var{seq}. It is
|
|
a destructive version of @code{cl-remove-duplicates}.
|
|
@end defun
|
|
|
|
@defun cl-substitute new old seq @t{&key :test :test-not :key :count :start :end :from-end}
|
|
This function returns a copy of @var{seq}, with all elements
|
|
matching @var{old} replaced with @var{new}. The @code{:count},
|
|
@code{:start}, @code{:end}, and @code{:from-end} arguments may be
|
|
used to limit the number of substitutions made.
|
|
@end defun
|
|
|
|
@defun cl-nsubstitute new old seq @t{&key :test :test-not :key :count :start :end :from-end}
|
|
This is a destructive version of @code{cl-substitute}; it performs
|
|
the substitution using @code{setcar} or @code{aset} rather than
|
|
by returning a changed copy of the sequence.
|
|
@end defun
|
|
|
|
@findex cl-substitute-if
|
|
@findex cl-substitute-if-not
|
|
@findex cl-nsubstitute-if
|
|
@findex cl-nsubstitute-if-not
|
|
The functions @code{cl-substitute-if}, @code{cl-substitute-if-not},
|
|
@code{cl-nsubstitute-if}, and @code{cl-nsubstitute-if-not} are defined
|
|
similarly. For these, a @var{predicate} is given in place of the
|
|
@var{old} argument.
|
|
|
|
@node Searching Sequences
|
|
@section Searching Sequences
|
|
|
|
@noindent
|
|
These functions search for elements or subsequences in a sequence.
|
|
(See also @code{cl-member} and @code{cl-assoc}; @pxref{Lists}.)
|
|
|
|
@defun cl-find item seq @t{&key :test :test-not :key :start :end :from-end}
|
|
This function searches @var{seq} for an element matching @var{item}.
|
|
If it finds a match, it returns the matching element. Otherwise,
|
|
it returns @code{nil}. It returns the leftmost match, unless
|
|
@code{:from-end} is true, in which case it returns the rightmost
|
|
match. The @code{:start} and @code{:end} arguments may be used to
|
|
limit the range of elements that are searched.
|
|
@end defun
|
|
|
|
@defun cl-position item seq @t{&key :test :test-not :key :start :end :from-end}
|
|
This function is like @code{cl-find}, except that it returns the
|
|
integer position in the sequence of the matching item rather than
|
|
the item itself. The position is relative to the start of the
|
|
sequence as a whole, even if @code{:start} is non-zero. The function
|
|
returns @code{nil} if no matching element was found.
|
|
@end defun
|
|
|
|
@defun cl-count item seq @t{&key :test :test-not :key :start :end}
|
|
This function returns the number of elements of @var{seq} which
|
|
match @var{item}. The result is always a nonnegative integer.
|
|
@end defun
|
|
|
|
@findex cl-find-if
|
|
@findex cl-find-if-not
|
|
@findex cl-position-if
|
|
@findex cl-position-if-not
|
|
@findex cl-count-if
|
|
@findex cl-count-if-not
|
|
The @code{cl-find-if}, @code{cl-find-if-not}, @code{cl-position-if},
|
|
@code{cl-position-if-not}, @code{cl-count-if}, and @code{cl-count-if-not}
|
|
functions are defined similarly.
|
|
|
|
@defun cl-mismatch seq1 seq2 @t{&key :test :test-not :key :start1 :end1 :start2 :end2 :from-end}
|
|
This function compares the specified parts of @var{seq1} and
|
|
@var{seq2}. If they are the same length and the corresponding
|
|
elements match (according to @code{:test}, @code{:test-not},
|
|
and @code{:key}), the function returns @code{nil}. If there is
|
|
a mismatch, the function returns the index (relative to @var{seq1})
|
|
of the first mismatching element. This will be the leftmost pair of
|
|
elements that do not match, or the position at which the shorter of
|
|
the two otherwise-matching sequences runs out.
|
|
|
|
If @code{:from-end} is true, then the elements are compared from right
|
|
to left starting at @code{(1- @var{end1})} and @code{(1- @var{end2})}.
|
|
If the sequences differ, then one plus the index of the rightmost
|
|
difference (relative to @var{seq1}) is returned.
|
|
|
|
An interesting example is @code{(cl-mismatch str1 str2 :key 'upcase)},
|
|
which compares two strings case-insensitively.
|
|
@end defun
|
|
|
|
@defun cl-search seq1 seq2 @t{&key :test :test-not :key :from-end :start1 :end1 :start2 :end2}
|
|
This function searches @var{seq2} for a subsequence that matches
|
|
@var{seq1} (or part of it specified by @code{:start1} and
|
|
@code{:end1}). Only matches that fall entirely within the region
|
|
defined by @code{:start2} and @code{:end2} will be considered.
|
|
The return value is the index of the leftmost element of the
|
|
leftmost match, relative to the start of @var{seq2}, or @code{nil}
|
|
if no matches were found. If @code{:from-end} is true, the
|
|
function finds the @emph{rightmost} matching subsequence.
|
|
@end defun
|
|
|
|
@node Sorting Sequences
|
|
@section Sorting Sequences
|
|
|
|
@defun cl-sort seq predicate @t{&key :key}
|
|
This function sorts @var{seq} into increasing order as determined
|
|
by using @var{predicate} to compare pairs of elements. @var{predicate}
|
|
should return true (non-@code{nil}) if and only if its first argument
|
|
is less than (not equal to) its second argument. For example,
|
|
@code{<} and @code{string-lessp} are suitable predicate functions
|
|
for sorting numbers and strings, respectively; @code{>} would sort
|
|
numbers into decreasing rather than increasing order.
|
|
|
|
This function differs from Emacs's built-in @code{sort} in that it
|
|
can operate on any type of sequence, not just lists. Also, it
|
|
accepts a @code{:key} argument, which is used to preprocess data
|
|
fed to the @var{predicate} function. For example,
|
|
|
|
@example
|
|
(setq data (cl-sort data 'string-lessp :key 'downcase))
|
|
@end example
|
|
|
|
@noindent
|
|
sorts @var{data}, a sequence of strings, into increasing alphabetical
|
|
order without regard to case. A @code{:key} function of @code{car}
|
|
would be useful for sorting association lists. It should only be a
|
|
simple accessor though, since it's used heavily in the current
|
|
implementation.
|
|
|
|
The @code{cl-sort} function is destructive; it sorts lists by actually
|
|
rearranging the @sc{cdr} pointers in suitable fashion.
|
|
@end defun
|
|
|
|
@defun cl-stable-sort seq predicate @t{&key :key}
|
|
This function sorts @var{seq} @dfn{stably}, meaning two elements
|
|
which are equal in terms of @var{predicate} are guaranteed not to
|
|
be rearranged out of their original order by the sort.
|
|
|
|
In practice, @code{cl-sort} and @code{cl-stable-sort} are equivalent
|
|
in Emacs Lisp because the underlying @code{sort} function is
|
|
stable by default. However, this package reserves the right to
|
|
use non-stable methods for @code{cl-sort} in the future.
|
|
@end defun
|
|
|
|
@defun cl-merge type seq1 seq2 predicate @t{&key :key}
|
|
This function merges two sequences @var{seq1} and @var{seq2} by
|
|
interleaving their elements. The result sequence, of type @var{type}
|
|
(in the sense of @code{cl-concatenate}), has length equal to the sum
|
|
of the lengths of the two input sequences. The sequences may be
|
|
modified destructively. Order of elements within @var{seq1} and
|
|
@var{seq2} is preserved in the interleaving; elements of the two
|
|
sequences are compared by @var{predicate} (in the sense of
|
|
@code{sort}) and the lesser element goes first in the result.
|
|
When elements are equal, those from @var{seq1} precede those from
|
|
@var{seq2} in the result. Thus, if @var{seq1} and @var{seq2} are
|
|
both sorted according to @var{predicate}, then the result will be
|
|
a merged sequence which is (stably) sorted according to
|
|
@var{predicate}.
|
|
@end defun
|
|
|
|
@node Lists
|
|
@chapter Lists
|
|
|
|
@noindent
|
|
The functions described here operate on lists.
|
|
|
|
@menu
|
|
* List Functions:: @code{cl-first}, @code{cl-list*}, etc.
|
|
* Substitution of Expressions:: @code{cl-subst}, @code{cl-sublis}, etc.
|
|
* Lists as Sets:: @code{cl-member}, @code{cl-adjoin}, @code{cl-union}, etc.
|
|
* Association Lists:: @code{cl-assoc}, @code{cl-acons}, @code{cl-pairlis}, etc.
|
|
@end menu
|
|
|
|
@node List Functions
|
|
@section List Functions
|
|
|
|
@noindent
|
|
This section describes a number of simple operations on lists,
|
|
i.e., chains of cons cells.
|
|
|
|
@defun cl-first x
|
|
This function is a synonym for @code{(car @var{x})}. Likewise,
|
|
the functions @code{cl-second}, @code{cl-third}, @dots{}, through
|
|
@code{cl-tenth} return the given element of the list @var{x}.
|
|
@end defun
|
|
|
|
@defun cl-rest x
|
|
This function is a synonym for @code{(cdr @var{x})}.
|
|
@end defun
|
|
|
|
@defun cl-endp x
|
|
This function acts like @code{null}, but signals an error if @code{x}
|
|
is neither a @code{nil} nor a cons cell.
|
|
@end defun
|
|
|
|
@defun cl-list-length x
|
|
This function returns the length of list @var{x}, exactly like
|
|
@code{(length @var{x})}, except that if @var{x} is a circular
|
|
list (where the @sc{cdr}-chain forms a loop rather than terminating
|
|
with @code{nil}), this function returns @code{nil}. (The regular
|
|
@code{length} function would get stuck if given a circular list.
|
|
See also the @code{safe-length} function.)
|
|
@end defun
|
|
|
|
@defun cl-list* arg &rest others
|
|
This function constructs a list of its arguments. The final
|
|
argument becomes the @sc{cdr} of the last cell constructed.
|
|
Thus, @code{(cl-list* @var{a} @var{b} @var{c})} is equivalent to
|
|
@code{(cons @var{a} (cons @var{b} @var{c}))}, and
|
|
@code{(cl-list* @var{a} @var{b} nil)} is equivalent to
|
|
@code{(list @var{a} @var{b})}.
|
|
@end defun
|
|
|
|
@defun cl-ldiff list sublist
|
|
If @var{sublist} is a sublist of @var{list}, i.e., is @code{eq} to
|
|
one of the cons cells of @var{list}, then this function returns
|
|
a copy of the part of @var{list} up to but not including
|
|
@var{sublist}. For example, @code{(cl-ldiff x (cddr x))} returns
|
|
the first two elements of the list @code{x}. The result is a
|
|
copy; the original @var{list} is not modified. If @var{sublist}
|
|
is not a sublist of @var{list}, a copy of the entire @var{list}
|
|
is returned.
|
|
@end defun
|
|
|
|
@defun cl-copy-list list
|
|
This function returns a copy of the list @var{list}. It copies
|
|
dotted lists like @code{(1 2 . 3)} correctly.
|
|
@end defun
|
|
|
|
@defun cl-tree-equal x y @t{&key :test :test-not :key}
|
|
This function compares two trees of cons cells. If @var{x} and
|
|
@var{y} are both cons cells, their @sc{car}s and @sc{cdr}s are
|
|
compared recursively. If neither @var{x} nor @var{y} is a cons
|
|
cell, they are compared by @code{eql}, or according to the
|
|
specified test. The @code{:key} function, if specified, is
|
|
applied to the elements of both trees. @xref{Sequences}.
|
|
@end defun
|
|
|
|
@node Substitution of Expressions
|
|
@section Substitution of Expressions
|
|
|
|
@noindent
|
|
These functions substitute elements throughout a tree of cons
|
|
cells. (@xref{Sequence Functions}, for the @code{cl-substitute}
|
|
function, which works on just the top-level elements of a list.)
|
|
|
|
@defun cl-subst new old tree @t{&key :test :test-not :key}
|
|
This function substitutes occurrences of @var{old} with @var{new}
|
|
in @var{tree}, a tree of cons cells. It returns a substituted
|
|
tree, which will be a copy except that it may share storage with
|
|
the argument @var{tree} in parts where no substitutions occurred.
|
|
The original @var{tree} is not modified. This function recurses
|
|
on, and compares against @var{old}, both @sc{car}s and @sc{cdr}s
|
|
of the component cons cells. If @var{old} is itself a cons cell,
|
|
then matching cells in the tree are substituted as usual without
|
|
recursively substituting in that cell. Comparisons with @var{old}
|
|
are done according to the specified test (@code{eql} by default).
|
|
The @code{:key} function is applied to the elements of the tree
|
|
but not to @var{old}.
|
|
@end defun
|
|
|
|
@defun cl-nsubst new old tree @t{&key :test :test-not :key}
|
|
This function is like @code{cl-subst}, except that it works by
|
|
destructive modification (by @code{setcar} or @code{setcdr})
|
|
rather than copying.
|
|
@end defun
|
|
|
|
@findex cl-subst-if
|
|
@findex cl-subst-if-not
|
|
@findex cl-nsubst-if
|
|
@findex cl-nsubst-if-not
|
|
The @code{cl-subst-if}, @code{cl-subst-if-not}, @code{cl-nsubst-if}, and
|
|
@code{cl-nsubst-if-not} functions are defined similarly.
|
|
|
|
@defun cl-sublis alist tree @t{&key :test :test-not :key}
|
|
This function is like @code{cl-subst}, except that it takes an
|
|
association list @var{alist} of @var{old}-@var{new} pairs.
|
|
Each element of the tree (after applying the @code{:key}
|
|
function, if any), is compared with the @sc{car}s of
|
|
@var{alist}; if it matches, it is replaced by the corresponding
|
|
@sc{cdr}.
|
|
@end defun
|
|
|
|
@defun cl-nsublis alist tree @t{&key :test :test-not :key}
|
|
This is a destructive version of @code{cl-sublis}.
|
|
@end defun
|
|
|
|
@node Lists as Sets
|
|
@section Lists as Sets
|
|
|
|
@noindent
|
|
These functions perform operations on lists that represent sets of
|
|
elements. All these functions (unless otherwise specified) default to
|
|
using @code{eql} as the test function, but that can be modified by the
|
|
@code{:test} parameter.
|
|
|
|
@defun cl-member item list @t{&key :test :test-not :key}
|
|
This function searches @var{list} for an element matching @var{item}.
|
|
If a match is found, it returns the cons cell whose @sc{car} was
|
|
the matching element. Otherwise, it returns @code{nil}. Elements
|
|
are compared by @code{eql} by default; you can use the @code{:test},
|
|
@code{:test-not}, and @code{:key} arguments to modify this behavior.
|
|
@xref{Sequences}.
|
|
|
|
The standard Emacs lisp function @code{member} uses @code{equal} for
|
|
comparisons; it is equivalent to @code{(cl-member @var{item} @var{list}
|
|
:test 'equal)}.
|
|
@end defun
|
|
|
|
@findex cl-member-if
|
|
@findex cl-member-if-not
|
|
The @code{cl-member-if} and @code{cl-member-if-not} functions
|
|
analogously search for elements that satisfy a given predicate.
|
|
|
|
@defun cl-tailp sublist list
|
|
This function returns @code{t} if @var{sublist} is a sublist of
|
|
@var{list}, i.e., if @var{sublist} is @code{eql} to @var{list} or to
|
|
any of its @sc{cdr}s.
|
|
@end defun
|
|
|
|
@defun cl-adjoin item list @t{&key :test :test-not :key}
|
|
This function conses @var{item} onto the front of @var{list},
|
|
like @code{(cons @var{item} @var{list})}, but only if @var{item}
|
|
is not already present on the list (as determined by @code{cl-member}).
|
|
If a @code{:key} argument is specified, it is applied to
|
|
@var{item} as well as to the elements of @var{list} during
|
|
the search, on the reasoning that @var{item} is ``about'' to
|
|
become part of the list.
|
|
@end defun
|
|
|
|
@defun cl-union list1 list2 @t{&key :test :test-not :key}
|
|
This function combines two lists that represent sets of items,
|
|
returning a list that represents the union of those two sets.
|
|
The resulting list contains all items that appear in @var{list1}
|
|
or @var{list2}, and no others. If an item appears in both
|
|
@var{list1} and @var{list2} it is copied only once. If
|
|
an item is duplicated in @var{list1} or @var{list2}, it is
|
|
undefined whether or not that duplication will survive in the
|
|
result list. The order of elements in the result list is also
|
|
undefined.
|
|
@end defun
|
|
|
|
@defun cl-nunion list1 list2 @t{&key :test :test-not :key}
|
|
This is a destructive version of @code{cl-union}; rather than copying,
|
|
it tries to reuse the storage of the argument lists if possible.
|
|
@end defun
|
|
|
|
@defun cl-intersection list1 list2 @t{&key :test :test-not :key}
|
|
This function computes the intersection of the sets represented
|
|
by @var{list1} and @var{list2}. It returns the list of items
|
|
that appear in both @var{list1} and @var{list2}.
|
|
@end defun
|
|
|
|
@defun cl-nintersection list1 list2 @t{&key :test :test-not :key}
|
|
This is a destructive version of @code{cl-intersection}. It
|
|
tries to reuse storage of @var{list1} rather than copying.
|
|
It does @emph{not} reuse the storage of @var{list2}.
|
|
@end defun
|
|
|
|
@defun cl-set-difference list1 list2 @t{&key :test :test-not :key}
|
|
This function computes the ``set difference'' of @var{list1}
|
|
and @var{list2}, i.e., the set of elements that appear in
|
|
@var{list1} but @emph{not} in @var{list2}.
|
|
@end defun
|
|
|
|
@defun cl-nset-difference list1 list2 @t{&key :test :test-not :key}
|
|
This is a destructive @code{cl-set-difference}, which will try
|
|
to reuse @var{list1} if possible.
|
|
@end defun
|
|
|
|
@defun cl-set-exclusive-or list1 list2 @t{&key :test :test-not :key}
|
|
This function computes the ``set exclusive or'' of @var{list1}
|
|
and @var{list2}, i.e., the set of elements that appear in
|
|
exactly one of @var{list1} and @var{list2}.
|
|
@end defun
|
|
|
|
@defun cl-nset-exclusive-or list1 list2 @t{&key :test :test-not :key}
|
|
This is a destructive @code{cl-set-exclusive-or}, which will try
|
|
to reuse @var{list1} and @var{list2} if possible.
|
|
@end defun
|
|
|
|
@defun cl-subsetp list1 list2 @t{&key :test :test-not :key}
|
|
This function checks whether @var{list1} represents a subset
|
|
of @var{list2}, i.e., whether every element of @var{list1}
|
|
also appears in @var{list2}.
|
|
@end defun
|
|
|
|
@node Association Lists
|
|
@section Association Lists
|
|
|
|
@noindent
|
|
An @dfn{association list} is a list representing a mapping from
|
|
one set of values to another; any list whose elements are cons
|
|
cells is an association list.
|
|
|
|
@defun cl-assoc item a-list @t{&key :test :test-not :key}
|
|
This function searches the association list @var{a-list} for an
|
|
element whose @sc{car} matches (in the sense of @code{:test},
|
|
@code{:test-not}, and @code{:key}, or by comparison with @code{eql})
|
|
a given @var{item}. It returns the matching element, if any,
|
|
otherwise @code{nil}. It ignores elements of @var{a-list} that
|
|
are not cons cells. (This corresponds to the behavior of
|
|
@code{assq} and @code{assoc} in Emacs Lisp; Common Lisp's
|
|
@code{assoc} ignores @code{nil}s but considers any other non-cons
|
|
elements of @var{a-list} to be an error.)
|
|
@end defun
|
|
|
|
@defun cl-rassoc item a-list @t{&key :test :test-not :key}
|
|
This function searches for an element whose @sc{cdr} matches
|
|
@var{item}. If @var{a-list} represents a mapping, this applies
|
|
the inverse of the mapping to @var{item}.
|
|
@end defun
|
|
|
|
@findex cl-assoc-if
|
|
@findex cl-assoc-if-not
|
|
@findex cl-rassoc-if
|
|
@findex cl-rassoc-if-not
|
|
The @code{cl-assoc-if}, @code{cl-assoc-if-not}, @code{cl-rassoc-if},
|
|
and @code{cl-rassoc-if-not} functions are defined similarly.
|
|
|
|
Two simple functions for constructing association lists are:
|
|
|
|
@defun cl-acons key value alist
|
|
This is equivalent to @code{(cons (cons @var{key} @var{value}) @var{alist})}.
|
|
@end defun
|
|
|
|
@defun cl-pairlis keys values &optional alist
|
|
This is equivalent to @code{(nconc (cl-mapcar 'cons @var{keys} @var{values})
|
|
@var{alist})}.
|
|
@end defun
|
|
|
|
@node Structures
|
|
@chapter Structures
|
|
|
|
@noindent
|
|
The Common Lisp @dfn{structure} mechanism provides a general way
|
|
to define data types similar to C's @code{struct} types. A
|
|
structure is a Lisp object containing some number of @dfn{slots},
|
|
each of which can hold any Lisp data object. Functions are
|
|
provided for accessing and setting the slots, creating or copying
|
|
structure objects, and recognizing objects of a particular structure
|
|
type.
|
|
|
|
In true Common Lisp, each structure type is a new type distinct
|
|
from all existing Lisp types. Since the underlying Emacs Lisp
|
|
system provides no way to create new distinct types, this package
|
|
implements structures as vectors (or lists upon request) with a
|
|
special ``tag'' symbol to identify them.
|
|
|
|
@defmac cl-defstruct name slots@dots{}
|
|
The @code{cl-defstruct} form defines a new structure type called
|
|
@var{name}, with the specified @var{slots}. (The @var{slots}
|
|
may begin with a string which documents the structure type.)
|
|
In the simplest case, @var{name} and each of the @var{slots}
|
|
are symbols. For example,
|
|
|
|
@example
|
|
(cl-defstruct person first-name age sex)
|
|
@end example
|
|
|
|
@noindent
|
|
defines a struct type called @code{person} that contains three slots.
|
|
Given a @code{person} object @var{p}, you can access those slots by
|
|
calling @code{(person-first-name @var{p})}, @code{(person-age
|
|
@var{p})}, and @code{(person-sex @var{p})}. You can also change these
|
|
slots by using @code{setf} on any of these place forms, for example:
|
|
|
|
@example
|
|
(cl-incf (person-age birthday-boy))
|
|
@end example
|
|
|
|
You can create a new @code{person} by calling @code{make-person},
|
|
which takes keyword arguments @code{:first-name}, @code{:age}, and
|
|
@code{:sex} to specify the initial values of these slots in the
|
|
new object. (Omitting any of these arguments leaves the corresponding
|
|
slot ``undefined'', according to the Common Lisp standard; in Emacs
|
|
Lisp, such uninitialized slots are filled with @code{nil}.)
|
|
|
|
Given a @code{person}, @code{(copy-person @var{p})} makes a new
|
|
object of the same type whose slots are @code{eq} to those of @var{p}.
|
|
|
|
Given any Lisp object @var{x}, @code{(person-p @var{x})} returns
|
|
true if @var{x} is a @code{person}, and false otherwise.
|
|
|
|
Accessors like @code{person-first-name} normally check their arguments
|
|
(effectively using @code{person-p}) and signal an error if the
|
|
argument is the wrong type. This check is affected by
|
|
@code{(optimize (safety @dots{}))} declarations. Safety level 1,
|
|
the default, uses a somewhat optimized check that will detect all
|
|
incorrect arguments, but may use an uninformative error message
|
|
(e.g., ``expected a vector'' instead of ``expected a @code{person}'').
|
|
Safety level 0 omits all checks except as provided by the underlying
|
|
@code{aref} call; safety levels 2 and 3 do rigorous checking that will
|
|
always print a descriptive error message for incorrect inputs.
|
|
@xref{Declarations}.
|
|
|
|
@example
|
|
(setq dave (make-person :first-name "Dave" :sex 'male))
|
|
@result{} [cl-struct-person "Dave" nil male]
|
|
(setq other (copy-person dave))
|
|
@result{} [cl-struct-person "Dave" nil male]
|
|
(eq dave other)
|
|
@result{} nil
|
|
(eq (person-first-name dave) (person-first-name other))
|
|
@result{} t
|
|
(person-p dave)
|
|
@result{} t
|
|
(person-p [1 2 3 4])
|
|
@result{} nil
|
|
(person-p "Bogus")
|
|
@result{} nil
|
|
(person-p '[cl-struct-person counterfeit person object])
|
|
@result{} t
|
|
@end example
|
|
|
|
In general, @var{name} is either a name symbol or a list of a name
|
|
symbol followed by any number of @dfn{structure options}; each @var{slot}
|
|
is either a slot symbol or a list of the form @samp{(@var{slot-name}
|
|
@var{default-value} @var{slot-options}@dots{})}. The @var{default-value}
|
|
is a Lisp form that is evaluated any time an instance of the
|
|
structure type is created without specifying that slot's value.
|
|
|
|
@example
|
|
(cl-defstruct person
|
|
(first-name nil :read-only t)
|
|
age
|
|
(sex 'unknown))
|
|
@end example
|
|
|
|
@var{slot-options} is a list of keyword-value pairs, where the
|
|
following keywords can be used:
|
|
|
|
@table @code
|
|
@item :read-only
|
|
A non-@code{nil} value means the slot should not be @code{setf}-able;
|
|
the slot's value is determined when the object is created and does
|
|
not change afterward.
|
|
|
|
@item :type
|
|
The expected type of the values held in this slot.
|
|
|
|
@item :documentation
|
|
A documentation string describing the slot.
|
|
@end table
|
|
|
|
Other slot options are currently ignored.
|
|
|
|
For obscure historical reasons, structure options take a different
|
|
form than slot options. A structure option is either a keyword
|
|
symbol, or a list beginning with a keyword symbol possibly followed
|
|
by arguments. (By contrast, slot options are key-value pairs not
|
|
enclosed in lists.)
|
|
|
|
@example
|
|
(cl-defstruct (person (:constructor create-person)
|
|
(:type list)
|
|
:named)
|
|
first-name age sex)
|
|
@end example
|
|
|
|
The following structure options are recognized.
|
|
|
|
@table @code
|
|
@item :conc-name
|
|
The argument is a symbol whose print name is used as the prefix for
|
|
the names of slot accessor functions. The default is the name of
|
|
the struct type followed by a hyphen. The option @code{(:conc-name p-)}
|
|
would change this prefix to @code{p-}. Specifying @code{nil} as an
|
|
argument means no prefix, so that the slot names themselves are used
|
|
to name the accessor functions.
|
|
|
|
@item :constructor
|
|
In the simple case, this option takes one argument which is an
|
|
alternate name to use for the constructor function. The default
|
|
is @code{make-@var{name}}, e.g., @code{make-person}. The above
|
|
example changes this to @code{create-person}. Specifying @code{nil}
|
|
as an argument means that no standard constructor should be
|
|
generated at all.
|
|
|
|
In the full form of this option, the constructor name is followed
|
|
by an arbitrary argument list. @xref{Program Structure}, for a
|
|
description of the format of Common Lisp argument lists. All
|
|
options, such as @code{&rest} and @code{&key}, are supported.
|
|
The argument names should match the slot names; each slot is
|
|
initialized from the corresponding argument. Slots whose names
|
|
do not appear in the argument list are initialized based on the
|
|
@var{default-value} in their slot descriptor. Also, @code{&optional}
|
|
and @code{&key} arguments that don't specify defaults take their
|
|
defaults from the slot descriptor. It is valid to include arguments
|
|
that don't correspond to slot names; these are useful if they are
|
|
referred to in the defaults for optional, keyword, or @code{&aux}
|
|
arguments that @emph{do} correspond to slots.
|
|
|
|
You can specify any number of full-format @code{:constructor}
|
|
options on a structure. The default constructor is still generated
|
|
as well unless you disable it with a simple-format @code{:constructor}
|
|
option.
|
|
|
|
@example
|
|
(cl-defstruct
|
|
(person
|
|
(:constructor nil) ; no default constructor
|
|
(:constructor new-person
|
|
(first-name sex &optional (age 0)))
|
|
(:constructor new-hound (&key (first-name "Rover")
|
|
(dog-years 0)
|
|
&aux (age (* 7 dog-years))
|
|
(sex 'canine))))
|
|
first-name age sex)
|
|
@end example
|
|
|
|
The first constructor here takes its arguments positionally rather
|
|
than by keyword. (In official Common Lisp terminology, constructors
|
|
that work By Order of Arguments instead of by keyword are called
|
|
``BOA constructors''. No, I'm not making this up.) For example,
|
|
@code{(new-person "Jane" 'female)} generates a person whose slots
|
|
are @code{"Jane"}, 0, and @code{female}, respectively.
|
|
|
|
The second constructor takes two keyword arguments, @code{:name},
|
|
which initializes the @code{name} slot and defaults to @code{"Rover"},
|
|
and @code{:dog-years}, which does not itself correspond to a slot
|
|
but which is used to initialize the @code{age} slot. The @code{sex}
|
|
slot is forced to the symbol @code{canine} with no syntax for
|
|
overriding it.
|
|
|
|
@item :copier
|
|
The argument is an alternate name for the copier function for
|
|
this type. The default is @code{copy-@var{name}}. @code{nil}
|
|
means not to generate a copier function. (In this implementation,
|
|
all copier functions are simply synonyms for @code{copy-sequence}.)
|
|
|
|
@item :predicate
|
|
The argument is an alternate name for the predicate that recognizes
|
|
objects of this type. The default is @code{@var{name}-p}. @code{nil}
|
|
means not to generate a predicate function. (If the @code{:type}
|
|
option is used without the @code{:named} option, no predicate is
|
|
ever generated.)
|
|
|
|
In true Common Lisp, @code{typep} is always able to recognize a
|
|
structure object even if @code{:predicate} was used. In this
|
|
package, @code{cl-typep} simply looks for a function called
|
|
@code{@var{typename}-p}, so it will work for structure types
|
|
only if they used the default predicate name.
|
|
|
|
@item :include
|
|
This option implements a very limited form of C@t{++}-style inheritance.
|
|
The argument is the name of another structure type previously
|
|
created with @code{cl-defstruct}. The effect is to cause the new
|
|
structure type to inherit all of the included structure's slots
|
|
(plus, of course, any new slots described by this struct's slot
|
|
descriptors). The new structure is considered a ``specialization''
|
|
of the included one. In fact, the predicate and slot accessors
|
|
for the included type will also accept objects of the new type.
|
|
|
|
If there are extra arguments to the @code{:include} option after
|
|
the included-structure name, these options are treated as replacement
|
|
slot descriptors for slots in the included structure, possibly with
|
|
modified default values. Borrowing an example from Steele:
|
|
|
|
@example
|
|
(cl-defstruct person first-name (age 0) sex)
|
|
@result{} person
|
|
(cl-defstruct (astronaut (:include person (age 45)))
|
|
helmet-size
|
|
(favorite-beverage 'tang))
|
|
@result{} astronaut
|
|
|
|
(setq joe (make-person :first-name "Joe"))
|
|
@result{} [cl-struct-person "Joe" 0 nil]
|
|
(setq buzz (make-astronaut :first-name "Buzz"))
|
|
@result{} [cl-struct-astronaut "Buzz" 45 nil nil tang]
|
|
|
|
(list (person-p joe) (person-p buzz))
|
|
@result{} (t t)
|
|
(list (astronaut-p joe) (astronaut-p buzz))
|
|
@result{} (nil t)
|
|
|
|
(person-first-name buzz)
|
|
@result{} "Buzz"
|
|
(astronaut-first-name joe)
|
|
@result{} error: "astronaut-first-name accessing a non-astronaut"
|
|
@end example
|
|
|
|
Thus, if @code{astronaut} is a specialization of @code{person},
|
|
then every @code{astronaut} is also a @code{person} (but not the
|
|
other way around). Every @code{astronaut} includes all the slots
|
|
of a @code{person}, plus extra slots that are specific to
|
|
astronauts. Operations that work on people (like @code{person-first-name})
|
|
work on astronauts just like other people.
|
|
|
|
@item :noinline
|
|
If this option is present, this structure's functions will not be
|
|
inlined, even functions that normally would.
|
|
|
|
@item :print-function
|
|
In full Common Lisp, this option allows you to specify a function
|
|
that is called to print an instance of the structure type. The
|
|
Emacs Lisp system offers no hooks into the Lisp printer which would
|
|
allow for such a feature, so this package simply ignores
|
|
@code{:print-function}.
|
|
|
|
@item :type
|
|
The argument should be one of the symbols @code{vector} or
|
|
@code{list}. This tells which underlying Lisp data type should be
|
|
used to implement the new structure type. Records are used by
|
|
default, but @code{(:type vector)} will cause structure objects to be
|
|
stored as vectors and @code{(:type list)} lists instead.
|
|
|
|
The record and vector representations for structure objects have the
|
|
advantage that all structure slots can be accessed quickly, although
|
|
creating them are a bit slower in Emacs Lisp. Lists are easier to
|
|
create, but take a relatively long time accessing the later slots.
|
|
|
|
@item :named
|
|
This option, which takes no arguments, causes a characteristic ``tag''
|
|
symbol to be stored at the front of the structure object. Using
|
|
@code{:type} without also using @code{:named} will result in a
|
|
structure type stored as plain vectors or lists with no identifying
|
|
features.
|
|
|
|
The default, if you don't specify @code{:type} explicitly, is to use
|
|
records, which are always tagged. Therefore, @code{:named} is only
|
|
useful in conjunction with @code{:type}.
|
|
|
|
@example
|
|
(cl-defstruct (person1) first-name age sex)
|
|
(cl-defstruct (person2 (:type list) :named) first-name age sex)
|
|
(cl-defstruct (person3 (:type list)) first-name age sex)
|
|
(cl-defstruct (person4 (:type vector)) first-name age sex)
|
|
|
|
(setq p1 (make-person1))
|
|
@result{} #s(person1 nil nil nil)
|
|
(setq p2 (make-person2))
|
|
@result{} (person2 nil nil nil)
|
|
(setq p3 (make-person3))
|
|
@result{} (nil nil nil)
|
|
(setq p4 (make-person4))
|
|
@result{} [nil nil nil]
|
|
|
|
(person1-p p1)
|
|
@result{} t
|
|
(person2-p p2)
|
|
@result{} t
|
|
(person3-p p3)
|
|
@result{} error: function person3-p undefined
|
|
@end example
|
|
|
|
Since unnamed structures don't have tags, @code{cl-defstruct} is not
|
|
able to make a useful predicate for recognizing them. Also,
|
|
accessors like @code{person3-first-name} will be generated but they
|
|
will not be able to do any type checking. The @code{person3-first-name}
|
|
function, for example, will simply be a synonym for @code{car} in
|
|
this case. By contrast, @code{person2-first-name} is able to verify
|
|
that its argument is indeed a @code{person2} object before
|
|
proceeding.
|
|
|
|
@item :initial-offset
|
|
The argument must be a nonnegative integer. It specifies a
|
|
number of slots to be left ``empty'' at the front of the
|
|
structure. If the structure is named, the tag appears at the
|
|
specified position in the list or vector; otherwise, the first
|
|
slot appears at that position. Earlier positions are filled
|
|
with @code{nil} by the constructors and ignored otherwise. If
|
|
the type @code{:include}s another type, then @code{:initial-offset}
|
|
specifies a number of slots to be skipped between the last slot
|
|
of the included type and the first new slot.
|
|
@end table
|
|
@end defmac
|
|
|
|
Except as noted, the @code{cl-defstruct} facility of this package is
|
|
entirely compatible with that of Common Lisp.
|
|
|
|
The @code{cl-defstruct} package also provides a few structure
|
|
introspection functions.
|
|
|
|
@defun cl-struct-sequence-type struct-type
|
|
This function returns the underlying data structure for
|
|
@code{struct-type}, which is a symbol. It returns @code{record},
|
|
@code{vector} or @code{list}, or @code{nil} if @code{struct-type} is
|
|
not actually a structure.
|
|
@end defun
|
|
|
|
@defun cl-struct-slot-info struct-type
|
|
This function returns a list of slot descriptors for structure
|
|
@code{struct-type}. Each entry in the list is @code{(name . opts)},
|
|
where @code{name} is the name of the slot and @code{opts} is the list
|
|
of slot options given to @code{defstruct}. Dummy entries represent
|
|
the slots used for the struct name and that are skipped to implement
|
|
@code{:initial-offset}.
|
|
@end defun
|
|
|
|
@defun cl-struct-slot-offset struct-type slot-name
|
|
Return the offset of slot @code{slot-name} in @code{struct-type}. The
|
|
returned zero-based slot index is relative to the start of the
|
|
structure data type and is adjusted for any structure name and
|
|
:initial-offset slots. Signal error if struct @code{struct-type} does
|
|
not contain @code{slot-name}.
|
|
@end defun
|
|
|
|
@defun cl-struct-slot-value struct-type slot-name inst
|
|
Return the value of slot @code{slot-name} in @code{inst} of
|
|
@code{struct-type}. @code{struct} and @code{slot-name} are symbols.
|
|
@code{inst} is a structure instance. This routine is also a
|
|
@code{setf} place. Can signal the same errors as @code{cl-struct-slot-offset}.
|
|
@end defun
|
|
|
|
@node Assertions
|
|
@chapter Assertions and Errors
|
|
|
|
@noindent
|
|
This section describes two macros that test @dfn{assertions}, i.e.,
|
|
conditions which must be true if the program is operating correctly.
|
|
Assertions never add to the behavior of a Lisp program; they simply
|
|
make ``sanity checks'' to make sure everything is as it should be.
|
|
|
|
If the optimization property @code{speed} has been set to 3, and
|
|
@code{safety} is less than 3, then the byte-compiler will optimize
|
|
away the following assertions. Because assertions might be optimized
|
|
away, it is a bad idea for them to include side-effects.
|
|
|
|
@defmac cl-assert test-form [show-args string args@dots{}]
|
|
This form verifies that @var{test-form} is true (i.e., evaluates to
|
|
a non-@code{nil} value). If so, it returns @code{nil}. If the test
|
|
is not satisfied, @code{cl-assert} signals an error.
|
|
|
|
A default error message will be supplied which includes @var{test-form}.
|
|
You can specify a different error message by including a @var{string}
|
|
argument plus optional extra arguments. Those arguments are simply
|
|
passed to @code{error} to signal the error.
|
|
|
|
If the optional second argument @var{show-args} is @code{t} instead
|
|
of @code{nil}, then the error message (with or without @var{string})
|
|
will also include all non-constant arguments of the top-level
|
|
@var{form}. For example:
|
|
|
|
@example
|
|
(cl-assert (> x 10) t "x is too small: %d")
|
|
@end example
|
|
|
|
This usage of @var{show-args} is an extension to Common Lisp. In
|
|
true Common Lisp, the second argument gives a list of @var{places}
|
|
which can be @code{setf}'d by the user before continuing from the
|
|
error. Since Emacs Lisp does not support continuable errors, it
|
|
makes no sense to specify @var{places}.
|
|
@end defmac
|
|
|
|
@defmac cl-check-type form type [string]
|
|
This form verifies that @var{form} evaluates to a value of type
|
|
@var{type}. If so, it returns @code{nil}. If not, @code{cl-check-type}
|
|
signals a @code{wrong-type-argument} error. The default error message
|
|
lists the erroneous value along with @var{type} and @var{form}
|
|
themselves. If @var{string} is specified, it is included in the
|
|
error message in place of @var{type}. For example:
|
|
|
|
@example
|
|
(cl-check-type x (integer 1 *) "a positive integer")
|
|
@end example
|
|
|
|
@xref{Type Predicates}, for a description of the type specifiers
|
|
that may be used for @var{type}.
|
|
|
|
Note that in Common Lisp, the first argument to @code{check-type}
|
|
must be a @var{place} suitable for use by @code{setf}, because
|
|
@code{check-type} signals a continuable error that allows the
|
|
user to modify @var{place}.
|
|
@end defmac
|
|
|
|
@node Efficiency Concerns
|
|
@appendix Efficiency Concerns
|
|
|
|
@appendixsec Macros
|
|
|
|
@noindent
|
|
Many of the advanced features of this package, such as @code{cl-defun},
|
|
@code{cl-loop}, etc., are implemented as Lisp macros. In
|
|
byte-compiled code, these complex notations will be expanded into
|
|
equivalent Lisp code which is simple and efficient. For example,
|
|
the form
|
|
|
|
@example
|
|
(cl-incf i n)
|
|
@end example
|
|
|
|
@noindent
|
|
is expanded at compile-time to the Lisp form
|
|
|
|
@example
|
|
(setq i (+ i n))
|
|
@end example
|
|
|
|
@noindent
|
|
which is the most efficient way of doing this operation
|
|
in Lisp. Thus, there is no performance penalty for using the more
|
|
readable @code{cl-incf} form in your compiled code.
|
|
|
|
@emph{Interpreted} code, on the other hand, must expand these macros
|
|
every time they are executed. For this reason it is strongly
|
|
recommended that code making heavy use of macros be compiled.
|
|
A loop using @code{cl-incf} a hundred times will execute considerably
|
|
faster if compiled, and will also garbage-collect less because the
|
|
macro expansion will not have to be generated, used, and thrown away a
|
|
hundred times.
|
|
|
|
You can find out how a macro expands by using the
|
|
@code{cl-prettyexpand} function.
|
|
|
|
@defun cl-prettyexpand form &optional full
|
|
This function takes a single Lisp form as an argument and inserts
|
|
a nicely formatted copy of it in the current buffer (which must be
|
|
in Lisp mode so that indentation works properly). It also expands
|
|
all Lisp macros that appear in the form. The easiest way to use
|
|
this function is to go to the @file{*scratch*} buffer and type, say,
|
|
|
|
@example
|
|
(cl-prettyexpand '(cl-loop for x below 10 collect x))
|
|
@end example
|
|
|
|
@noindent
|
|
and type @kbd{C-x C-e} immediately after the closing parenthesis;
|
|
an expansion similar to:
|
|
|
|
@example
|
|
(cl-block nil
|
|
(let* ((x 0)
|
|
(G1004 nil))
|
|
(while (< x 10)
|
|
(setq G1004 (cons x G1004))
|
|
(setq x (+ x 1)))
|
|
(nreverse G1004)))
|
|
@end example
|
|
|
|
@noindent
|
|
will be inserted into the buffer. (The @code{cl-block} macro is
|
|
expanded differently in the interpreter and compiler, so
|
|
@code{cl-prettyexpand} just leaves it alone. The temporary
|
|
variable @code{G1004} was created by @code{cl-gensym}.)
|
|
|
|
If the optional argument @var{full} is true, then @emph{all}
|
|
macros are expanded, including @code{cl-block}, @code{cl-eval-when},
|
|
and compiler macros. Expansion is done as if @var{form} were
|
|
a top-level form in a file being compiled.
|
|
|
|
@c FIXME none of these examples are still applicable.
|
|
@ignore
|
|
For example,
|
|
|
|
@example
|
|
(cl-prettyexpand '(cl-pushnew 'x list))
|
|
@print{} (setq list (cl-adjoin 'x list))
|
|
(cl-prettyexpand '(cl-pushnew 'x list) t)
|
|
@print{} (setq list (if (memq 'x list) list (cons 'x list)))
|
|
(cl-prettyexpand '(caddr (cl-member 'a list)) t)
|
|
@print{} (car (cdr (cdr (memq 'a list))))
|
|
@end example
|
|
@end ignore
|
|
|
|
Note that @code{cl-adjoin} and @code{cl-member} have built-in compiler
|
|
macros to optimize them in common cases.
|
|
@end defun
|
|
|
|
@appendixsec Error Checking
|
|
|
|
@noindent
|
|
Common Lisp compliance has in general not been sacrificed for the
|
|
sake of efficiency. A few exceptions have been made for cases
|
|
where substantial gains were possible at the expense of marginal
|
|
incompatibility.
|
|
|
|
The Common Lisp standard (as embodied in Steele's book) uses the
|
|
phrase ``it is an error if'' to indicate a situation that is not
|
|
supposed to arise in complying programs; implementations are strongly
|
|
encouraged but not required to signal an error in these situations.
|
|
This package sometimes omits such error checking in the interest of
|
|
compactness and efficiency. For example, @code{cl-do} variable
|
|
specifiers are supposed to be lists of one, two, or three forms; extra
|
|
forms are ignored by this package rather than signaling a syntax
|
|
error. Functions taking keyword arguments will accept an odd number
|
|
of arguments, treating the trailing keyword as if it were followed by
|
|
the value @code{nil}.
|
|
|
|
Argument lists (as processed by @code{cl-defun} and friends)
|
|
@emph{are} checked rigorously except for the minor point just
|
|
mentioned; in particular, keyword arguments are checked for
|
|
validity, and @code{&allow-other-keys} and @code{:allow-other-keys}
|
|
are fully implemented. Keyword validity checking is slightly
|
|
time consuming (though not too bad in byte-compiled code);
|
|
you can use @code{&allow-other-keys} to omit this check. Functions
|
|
defined in this package such as @code{cl-find} and @code{cl-member}
|
|
do check their keyword arguments for validity.
|
|
|
|
@appendixsec Compiler Optimizations
|
|
|
|
@noindent
|
|
Changing the value of @code{byte-optimize} from the default @code{t}
|
|
is highly discouraged; many of the Common
|
|
Lisp macros emit
|
|
code that can be improved by optimization. In particular,
|
|
@code{cl-block}s (whether explicit or implicit in constructs like
|
|
@code{cl-defun} and @code{cl-loop}) carry a fair run-time penalty; the
|
|
byte-compiler removes @code{cl-block}s that are not actually
|
|
referenced by @code{cl-return} or @code{cl-return-from} inside the block.
|
|
|
|
@node Common Lisp Compatibility
|
|
@appendix Common Lisp Compatibility
|
|
|
|
@noindent
|
|
The following is a list of some of the most important
|
|
incompatibilities between this package and Common Lisp as documented
|
|
in Steele (2nd edition).
|
|
|
|
The word @code{cl-defun} is required instead of @code{defun} in order
|
|
to use extended Common Lisp argument lists in a function. Likewise,
|
|
@code{cl-defmacro} and @code{cl-function} are versions of those forms
|
|
which understand full-featured argument lists. The @code{&whole}
|
|
keyword does not work in @code{cl-defmacro} argument lists (except
|
|
inside recursive argument lists).
|
|
|
|
The @code{equal} predicate does not distinguish
|
|
between IEEE floating-point plus and minus zero. The @code{cl-equalp}
|
|
predicate has several differences with Common Lisp; @pxref{Predicates}.
|
|
|
|
The @code{cl-do-all-symbols} form is the same as @code{cl-do-symbols}
|
|
with no @var{obarray} argument. In Common Lisp, this form would
|
|
iterate over all symbols in all packages. Since Emacs obarrays
|
|
are not a first-class package mechanism, there is no way for
|
|
@code{cl-do-all-symbols} to locate any but the default obarray.
|
|
|
|
The @code{cl-loop} macro is complete except that @code{loop-finish}
|
|
and type specifiers are unimplemented.
|
|
|
|
The multiple-value return facility treats lists as multiple
|
|
values, since Emacs Lisp cannot support multiple return values
|
|
directly. The macros will be compatible with Common Lisp if
|
|
@code{cl-values} or @code{cl-values-list} is always used to return to
|
|
a @code{cl-multiple-value-bind} or other multiple-value receiver;
|
|
if @code{cl-values} is used without @code{cl-multiple-value-@dots{}}
|
|
or vice-versa the effect will be different from Common Lisp.
|
|
|
|
Many Common Lisp declarations are ignored, and others match
|
|
the Common Lisp standard in concept but not in detail. For
|
|
example, local @code{special} declarations, which are purely
|
|
advisory in Emacs Lisp, do not rigorously obey the scoping rules
|
|
set down in Steele's book.
|
|
|
|
The variable @code{cl--gensym-counter} starts out with zero.
|
|
|
|
The @code{cl-defstruct} facility is compatible, except that the
|
|
@code{:type} slot option is ignored.
|
|
|
|
The second argument of @code{cl-check-type} is treated differently.
|
|
|
|
@node Porting Common Lisp
|
|
@appendix Porting Common Lisp
|
|
|
|
@noindent
|
|
This package is meant to be used as an extension to Emacs Lisp,
|
|
not as an Emacs implementation of true Common Lisp. Some of the
|
|
remaining differences between Emacs Lisp and Common Lisp make it
|
|
difficult to port large Common Lisp applications to Emacs. For
|
|
one, some of the features in this package are not fully compliant
|
|
with ANSI or Steele; @pxref{Common Lisp Compatibility}. But there
|
|
are also quite a few features that this package does not provide
|
|
at all. Here are some major omissions that you will want to watch out
|
|
for when bringing Common Lisp code into Emacs.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Case-insensitivity. Symbols in Common Lisp are case-insensitive
|
|
by default. Some programs refer to a function or variable as
|
|
@code{foo} in one place and @code{Foo} or @code{FOO} in another.
|
|
Emacs Lisp will treat these as three distinct symbols.
|
|
|
|
Some Common Lisp code is written entirely in upper case. While Emacs
|
|
is happy to let the program's own functions and variables use
|
|
this convention, calls to Lisp builtins like @code{if} and
|
|
@code{defun} will have to be changed to lower case.
|
|
|
|
@item
|
|
Lexical scoping. In Common Lisp, function arguments and @code{let}
|
|
bindings apply only to references physically within their bodies (or
|
|
within macro expansions in their bodies). Traditionally, Emacs Lisp
|
|
uses @dfn{dynamic scoping} wherein a binding to a variable is visible
|
|
even inside functions called from the body.
|
|
@xref{Dynamic Binding,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
Lexical binding is available since Emacs 24.1, so be sure to set
|
|
@code{lexical-binding} to @code{t} if you need to emulate this aspect
|
|
of Common Lisp. @xref{Lexical Binding,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
|
|
Here is an example of a Common Lisp code fragment that would fail in
|
|
Emacs Lisp if @code{lexical-binding} were set to @code{nil}:
|
|
|
|
@example
|
|
(defun map-odd-elements (func list)
|
|
(loop for x in list
|
|
for flag = t then (not flag)
|
|
collect (if flag x (funcall func x))))
|
|
|
|
(defun add-odd-elements (list x)
|
|
(map-odd-elements (lambda (a) (+ a x)) list))
|
|
@end example
|
|
|
|
@noindent
|
|
With lexical binding, the two functions' usages of @code{x} are
|
|
completely independent. With dynamic binding, the binding to @code{x}
|
|
made by @code{add-odd-elements} will have been hidden by the binding
|
|
in @code{map-odd-elements} by the time the @code{(+ a x)} function is
|
|
called.
|
|
|
|
Internally, this package uses lexical binding so that such problems do
|
|
not occur. @xref{Obsolete Lexical Binding}, for a description of the obsolete
|
|
@code{lexical-let} form that emulates a Common Lisp-style lexical
|
|
binding when dynamic binding is in use.
|
|
|
|
@item
|
|
Reader macros. Common Lisp includes a second type of macro that
|
|
works at the level of individual characters. For example, Common
|
|
Lisp implements the quote notation by a reader macro called @code{'},
|
|
whereas Emacs Lisp's parser just treats quote as a special case.
|
|
Some Lisp packages use reader macros to create special syntaxes
|
|
for themselves, which the Emacs parser is incapable of reading.
|
|
|
|
@item
|
|
Other syntactic features. Common Lisp provides a number of
|
|
notations beginning with @code{#} that the Emacs Lisp parser
|
|
won't understand. For example, @samp{#| @dots{} |#} is an
|
|
alternate comment notation, and @samp{#+lucid (foo)} tells
|
|
the parser to ignore the @code{(foo)} except in Lucid Common
|
|
Lisp.
|
|
|
|
@item
|
|
Packages. In Common Lisp, symbols are divided into @dfn{packages}.
|
|
Symbols that are Lisp built-ins are typically stored in one package;
|
|
symbols that are vendor extensions are put in another, and each
|
|
application program would have a package for its own symbols.
|
|
Certain symbols are ``exported'' by a package and others are
|
|
internal; certain packages ``use'' or import the exported symbols
|
|
of other packages. To access symbols that would not normally be
|
|
visible due to this importing and exporting, Common Lisp provides
|
|
a syntax like @code{package:symbol} or @code{package::symbol}.
|
|
|
|
Emacs Lisp has a single namespace for all interned symbols, and
|
|
then uses a naming convention of putting a prefix like @code{cl-}
|
|
in front of the name. Some Emacs packages adopt the Common Lisp-like
|
|
convention of using @code{cl:} or @code{cl::} as the prefix.
|
|
However, the Emacs parser does not understand colons and just
|
|
treats them as part of the symbol name. Thus, while @code{mapcar}
|
|
and @code{lisp:mapcar} may refer to the same symbol in Common
|
|
Lisp, they are totally distinct in Emacs Lisp. Common Lisp
|
|
programs that refer to a symbol by the full name sometimes
|
|
and the short name other times will not port cleanly to Emacs.
|
|
|
|
Emacs Lisp does have a concept of ``obarrays'', which are
|
|
package-like collections of symbols, but this feature is not
|
|
strong enough to be used as a true package mechanism.
|
|
|
|
@item
|
|
The @code{format} function is quite different between Common
|
|
Lisp and Emacs Lisp. It takes an additional ``destination''
|
|
argument before the format string. A destination of @code{nil}
|
|
means to format to a string as in Emacs Lisp; a destination
|
|
of @code{t} means to write to the terminal (similar to
|
|
@code{message} in Emacs). Also, format control strings are
|
|
utterly different; @code{~} is used instead of @code{%} to
|
|
introduce format codes, and the set of available codes is
|
|
much richer. There are no notations like @code{\n} for
|
|
string literals; instead, @code{format} is used with the
|
|
``newline'' format code, @code{~%}. More advanced formatting
|
|
codes provide such features as paragraph filling, case
|
|
conversion, and even loops and conditionals.
|
|
|
|
While it would have been possible to implement most of Common
|
|
Lisp @code{format} in this package (under the name @code{cl-format},
|
|
of course), it was not deemed worthwhile. It would have required
|
|
a huge amount of code to implement even a decent subset of
|
|
@code{format}, yet the functionality it would provide over
|
|
Emacs Lisp's @code{format} would rarely be useful.
|
|
|
|
@item
|
|
Vector constants use square brackets in Emacs Lisp, but
|
|
@code{#(a b c)} notation in Common Lisp. To further complicate
|
|
matters, Emacs has its own @code{#(} notation for
|
|
something entirely different---strings with properties.
|
|
|
|
@item
|
|
Characters are distinct from integers in Common Lisp. The notation
|
|
for character constants is also different: @code{#\A} in Common Lisp
|
|
where Emacs Lisp uses @code{?A}. Also, @code{string=} and
|
|
@code{string-equal} are synonyms in Emacs Lisp, whereas the latter is
|
|
case-insensitive in Common Lisp.
|
|
|
|
@item
|
|
Data types. Some Common Lisp data types do not exist in Emacs
|
|
Lisp. Rational numbers and complex numbers are not present,
|
|
nor are large integers (all integers are ``fixnums''). All
|
|
arrays are one-dimensional. There are no readtables or pathnames;
|
|
streams are a set of existing data types rather than a new data
|
|
type of their own. Hash tables, random-states, and packages
|
|
(obarrays) are built from Lisp vectors or lists rather than being
|
|
distinct types.
|
|
|
|
@item
|
|
The Common Lisp Object System (CLOS) is not implemented,
|
|
nor is the Common Lisp Condition System. However, the EIEIO package
|
|
(@pxref{Top, , Introduction, eieio, EIEIO}) does implement some
|
|
CLOS functionality.
|
|
|
|
@item
|
|
Common Lisp features that are completely redundant with Emacs
|
|
Lisp features of a different name generally have not been
|
|
implemented. For example, Common Lisp writes @code{defconstant}
|
|
where Emacs Lisp uses @code{defconst}. Similarly, @code{make-list}
|
|
takes its arguments in different ways in the two Lisps but does
|
|
exactly the same thing, so this package has not bothered to
|
|
implement a Common Lisp-style @code{make-list}.
|
|
|
|
@item
|
|
A few more notable Common Lisp features not included in this package:
|
|
@code{compiler-let}, @code{prog}, @code{ldb/dpb}, @code{cerror}.
|
|
|
|
@item
|
|
Recursion. While recursion works in Emacs Lisp just like it
|
|
does in Common Lisp, various details of the Emacs Lisp system
|
|
and compiler make recursion much less efficient than it is in
|
|
most Lisps. Some schools of thought prefer to use recursion
|
|
in Lisp over other techniques; they would sum a list of
|
|
numbers using something like
|
|
|
|
@example
|
|
(defun sum-list (list)
|
|
(if list
|
|
(+ (car list) (sum-list (cdr list)))
|
|
0))
|
|
@end example
|
|
|
|
@noindent
|
|
where a more iteratively-minded programmer might write one of
|
|
these forms:
|
|
|
|
@example
|
|
(let ((total 0)) (dolist (x my-list) (incf total x)) total)
|
|
(loop for x in my-list sum x)
|
|
@end example
|
|
|
|
While this would be mainly a stylistic choice in most Common Lisps,
|
|
in Emacs Lisp you should be aware that the iterative forms are
|
|
much faster than recursion. Also, Lisp programmers will want to
|
|
note that the current Emacs Lisp compiler does not optimize tail
|
|
recursion.
|
|
@end itemize
|
|
|
|
@node Obsolete Features
|
|
@appendix Obsolete Features
|
|
|
|
This section describes some features of the package that are obsolete
|
|
and should not be used in new code. They are either only provided by
|
|
the old @file{cl.el} entry point, not by the newer @file{cl-lib.el};
|
|
or where versions with a @samp{cl-} prefix do exist they do not behave
|
|
in exactly the same way.
|
|
|
|
@menu
|
|
* Obsolete Lexical Binding:: An approximation of lexical binding.
|
|
* Obsolete Macros:: Obsolete macros.
|
|
* Obsolete Setf Customization:: Obsolete ways to customize setf.
|
|
@end menu
|
|
|
|
@node Obsolete Lexical Binding
|
|
@appendixsec Obsolete Lexical Binding
|
|
|
|
The following macros are extensions to Common Lisp, where all bindings
|
|
are lexical unless declared otherwise. These features are likewise
|
|
obsolete since the introduction of true lexical binding in Emacs 24.1.
|
|
|
|
@defmac lexical-let (bindings@dots{}) forms@dots{}
|
|
This form is exactly like @code{let} except that the bindings it
|
|
establishes are purely lexical.
|
|
@end defmac
|
|
|
|
@c FIXME remove this and refer to elisp manual.
|
|
@c Maybe merge some stuff from here to there?
|
|
@noindent
|
|
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 (@pxref{Closures,,,elisp,GNU Emacs Lisp Reference Manual}).
|
|
For example:
|
|
|
|
@example
|
|
(defun make-adder (n)
|
|
(lexical-let ((n n))
|
|
(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))
|
|
(cl-function (lambda (&optional (m 1)) (cl-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.
|
|
|
|
@defmac 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 defmac
|
|
|
|
@node Obsolete Macros
|
|
@appendixsec Obsolete Macros
|
|
|
|
The following macros are obsolete, and are replaced by versions with
|
|
a @samp{cl-} prefix that do not behave in exactly the same way.
|
|
Consequently, the @file{cl.el} versions are not simply aliases to the
|
|
@file{cl-lib.el} versions.
|
|
|
|
@defmac flet (bindings@dots{}) forms@dots{}
|
|
This macro is replaced by @code{cl-flet} (@pxref{Function Bindings}),
|
|
which behaves the same way as Common Lisp's @code{flet}.
|
|
This @code{flet} takes the same arguments as @code{cl-flet}, but does
|
|
not behave in precisely the same way.
|
|
|
|
While @code{flet} in Common Lisp establishes a lexical function
|
|
binding, this @code{flet} makes a dynamic binding (it dates from a
|
|
time before Emacs had lexical binding). The result is
|
|
that @code{flet} affects indirect calls to a function as well as calls
|
|
directly inside the @code{flet} form itself.
|
|
|
|
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.
|
|
|
|
For those cases where the dynamic scoping of @code{flet} is desired,
|
|
@code{cl-flet} is clearly not a substitute. The most direct replacement would
|
|
be instead to use @code{cl-letf} to temporarily rebind @code{(symbol-function
|
|
'@var{fun})}. But in most cases, a better substitute is to use advice, such
|
|
as:
|
|
|
|
@example
|
|
(defvar my-fun-advice-enable nil)
|
|
(add-advice '@var{fun} :around
|
|
(lambda (orig &rest args)
|
|
(if my-fun-advice-enable (do-something)
|
|
(apply orig args))))
|
|
@end example
|
|
|
|
so that you can then replace the @code{flet} with a simple dynamically scoped
|
|
binding of @code{my-fun-advice-enable}.
|
|
|
|
@c Bug#411.
|
|
Note that many primitives (e.g., @code{+}) have special byte-compile handling.
|
|
Attempts to redefine such functions using @code{flet}, @code{cl-letf}, or
|
|
advice will fail when byte-compiled.
|
|
@c Or cl-flet.
|
|
@c In such cases, use @code{labels} instead.
|
|
@end defmac
|
|
|
|
@defmac labels (bindings@dots{}) forms@dots{}
|
|
This macro is replaced by @code{cl-labels} (@pxref{Function Bindings}),
|
|
which behaves the same way as Common Lisp's @code{labels}.
|
|
This @code{labels} takes the same arguments as @code{cl-labels}, but
|
|
does not behave in precisely the same way.
|
|
|
|
This version of @code{labels} uses the obsolete @code{lexical-let}
|
|
form (@pxref{Obsolete Lexical Binding}), rather than the true
|
|
lexical binding that @code{cl-labels} uses.
|
|
@end defmac
|
|
|
|
@node Obsolete Setf Customization
|
|
@appendixsec Obsolete Ways to Customize Setf
|
|
|
|
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.
|
|
In Emacs, these are obsolete, replaced by various features of
|
|
@file{gv.el} in Emacs 24.3.
|
|
@xref{Adding Generalized Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
|
|
|
|
|
|
@defmac define-modify-macro name arglist function [doc-string]
|
|
This macro defines a ``read-modify-write'' macro similar to
|
|
@code{cl-incf} and @code{cl-decf}. You can replace this macro
|
|
with @code{gv-letplace}.
|
|
|
|
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}@dots{})
|
|
@end example
|
|
|
|
@noindent
|
|
will be expanded to
|
|
|
|
@example
|
|
(cl-callf @var{func} @var{place} @var{args}@dots{})
|
|
@end example
|
|
|
|
@noindent
|
|
which in turn is roughly equivalent to
|
|
|
|
@example
|
|
(setf @var{place} (@var{func} @var{place} @var{args}@dots{}))
|
|
@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.
|
|
|
|
The above @code{incf} example could be written using
|
|
@code{gv-letplace} as:
|
|
@example
|
|
(defmacro incf (place &optional n)
|
|
(gv-letplace (getter setter) place
|
|
(cl-once-only ((v (or n 1)))
|
|
(funcall setter `(+ ,v ,getter)))))
|
|
@end example
|
|
@ignore
|
|
(defmacro concatf (place &rest args)
|
|
(gv-letplace (getter setter) place
|
|
(cl-once-only ((v `(mapconcat 'identity ',args)))
|
|
(funcall setter `(concat ,getter ,v)))))
|
|
@end ignore
|
|
@end defmac
|
|
|
|
@defmac defsetf access-fn update-fn
|
|
This is the simpler of two @code{defsetf} forms, and is
|
|
replaced by @code{gv-define-simple-setter}.
|
|
|
|
With @var{access-fn} the name of a function that 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 that 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 return value of @code{update-fn} 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 are:
|
|
|
|
@example
|
|
(defsetf car setcar)
|
|
(defsetf buffer-name rename-buffer t)
|
|
@end example
|
|
|
|
These translate directly to @code{gv-define-simple-setter}:
|
|
|
|
@example
|
|
(gv-define-simple-setter car setcar)
|
|
(gv-define-simple-setter buffer-name rename-buffer t)
|
|
@end example
|
|
@end defmac
|
|
|
|
@defmac defsetf access-fn arglist (store-var) forms@dots{}
|
|
This is the second, more complex, form of @code{defsetf}.
|
|
It can be replaced by @code{gv-define-setter}.
|
|
|
|
This form of @code{defsetf} is rather like @code{defmacro} except for
|
|
the additional @var{store-var} argument. The @var{forms} should
|
|
return a Lisp form that 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{cl-incf} that invoke this
|
|
setf-method will insert temporary variables as needed to make
|
|
sure the apparent order of evaluation is preserved.
|
|
|
|
Another standard example:
|
|
|
|
@example
|
|
(defsetf nth (n x) (store)
|
|
`(setcar (nthcdr ,n ,x) ,store))
|
|
@end example
|
|
|
|
You could write this using @code{gv-define-setter} as:
|
|
|
|
@example
|
|
(gv-define-setter nth (store n x)
|
|
`(setcar (nthcdr ,n ,x) ,store))
|
|
@end example
|
|
@end defmac
|
|
|
|
@defmac define-setf-method access-fn arglist forms@dots{}
|
|
This is the most general way to create new place forms. You can
|
|
replace this by @code{gv-define-setter} or @code{gv-define-expander}.
|
|
|
|
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 that stores the contents of the store variable into
|
|
the generalized variable, assuming the temporaries have been
|
|
bound as described above.
|
|
|
|
@item
|
|
A Lisp form that 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.
|
|
(Note that the @code{setf} implementation provided by @file{gv.el}
|
|
does not use this five item format. Its use here is only for
|
|
backwards compatibility.)
|
|
|
|
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
|
|
@c FIXME I don't think this is true anymore.
|
|
by @code{cl-gensym}. Macros like @code{cl-incf} that
|
|
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 defmac
|
|
|
|
@c Removed in Emacs 24.3, not possible to make a compatible replacement.
|
|
@ignore
|
|
@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{cl-incf}-like modify macros.
|
|
|
|
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}.
|
|
@end defun
|
|
@end ignore
|
|
|
|
|
|
@node GNU Free Documentation License
|
|
@appendix GNU Free Documentation License
|
|
@include doclicense.texi
|
|
|
|
@node Function Index
|
|
@unnumbered Function Index
|
|
@printindex fn
|
|
|
|
@node Variable Index
|
|
@unnumbered Variable Index
|
|
@printindex vr
|
|
|
|
@node Concept Index
|
|
@unnumbered Concept Index
|
|
@printindex cp
|
|
|
|
@bye
|