@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual.
-@c Copyright (C) 1990-1994, 1998, 2001-2012 Free Software Foundation, Inc.
+@c Copyright (C) 1990-1994, 1998, 2001-2015 Free Software Foundation,
+@c Inc.
@c See the file elisp.texi for copying conditions.
@node Evaluation
@chapter Evaluation
@cindex form
@cindex expression
@cindex S-expression
+@cindex sexp
A Lisp object that is intended for evaluation is called a @dfn{form}
or @dfn{expression}@footnote{It is sometimes also referred to as an
@dfn{S-expression} or @dfn{sexp}, but we generally do not use this
about symbol function indirection.
One possible consequence of this process is an infinite loop, in the
-event that a symbol's function cell refers to the same symbol. Or a
-symbol may have a void function cell, in which case the subroutine
-@code{symbol-function} signals a @code{void-function} error. But if
-neither of these things happens, we eventually obtain a non-symbol,
-which ought to be a function or other suitable object.
+event that a symbol's function cell refers to the same symbol.
+Otherwise, we eventually obtain a non-symbol, which ought to be a
+function or other suitable object.
@kindex invalid-function
More precisely, we should now have a Lisp function (a lambda
described in one of the following sections. If the object is not one
of these types, Emacs signals an @code{invalid-function} error.
- The following example illustrates the symbol indirection process. We
-use @code{fset} to set the function cell of a symbol and
+ The following example illustrates the symbol indirection process.
+We use @code{fset} to set the function cell of a symbol and
@code{symbol-function} to get the function cell contents
-(@pxref{Function Cells}). Specifically, we store the symbol @code{car}
-into the function cell of @code{first}, and the symbol @code{first} into
-the function cell of @code{erste}.
+(@pxref{Function Cells}). Specifically, we store the symbol
+@code{car} into the function cell of @code{first}, and the symbol
+@code{first} into the function cell of @code{erste}.
@example
@group
and which are used without evaluation. Whether a particular argument is
evaluated may depend on the results of evaluating other arguments.
+ If an expression's first symbol is that of a special form, the
+expression should follow the rules of that special form; otherwise,
+Emacs's behavior is not well-defined (though it will not crash). For
+example, @code{((lambda (x) x . 3) 4)} contains a subexpression that
+begins with @code{lambda} but is not a well-formed @code{lambda}
+expression, so Emacs may signal an error, or may return 3 or 4 or
+@code{nil}, or may behave in other ways.
+
+@defun special-form-p object
+This predicate tests whether its argument is a special form, and
+returns @code{t} if so, @code{nil} otherwise.
+@end defun
+
Here is a list, in alphabetical order, of all of the special forms in
Emacs Lisp with a reference to where each is described.
@item defconst
@pxref{Defining Variables}
-@item defmacro
-@pxref{Defining Macros}
-
-@item defun
-@pxref{Defining Functions}
-
@item defvar
@pxref{Defining Variables}
@item interactive
@pxref{Interactive Call}
+@item lambda
+@pxref{Lambda Expressions}
+
@item let
@itemx let*
@pxref{Local Variables}
@item save-restriction
@pxref{Narrowing}
-@item save-window-excursion
-@pxref{Window Configurations}
-
@item setq
@pxref{Setting Variables}
@item while
@pxref{Iteration}
-
-@item with-output-to-temp-buffer
-@pxref{Temporary Displays}
@end table
@cindex CL note---special forms compared
@b{Common Lisp note:} Here are some comparisons of special forms in
GNU Emacs Lisp and Common Lisp. @code{setq}, @code{if}, and
@code{catch} are special forms in both Emacs Lisp and Common Lisp.
-@code{defun} is a special form in Emacs Lisp, but a macro in Common
-Lisp. @code{save-excursion} is a special form in Emacs Lisp, but
+@code{save-excursion} is a special form in Emacs Lisp, but
doesn't exist in Common Lisp. @code{throw} is a special form in
Common Lisp (because it must be able to throw multiple values), but it
is a function in Emacs Lisp (which doesn't have multiple
-values).@refill
+values).
@end quotation
@node Autoloading
@defun eval form &optional lexical
This is the basic function for evaluating an expression. It evaluates
-@var{form} in the current environment and returns the result. How the
-evaluation proceeds depends on the type of the object (@pxref{Forms}).
-
-The argument @var{lexical}, if non-@code{nil}, means to evaluate
-@var{form} using lexical scoping rules for variables, instead of the
-default dynamic scoping rules. @xref{Lexical Binding}.
+@var{form} in the current environment, and returns the result. The
+type of the @var{form} object determines how it is evaluated.
+@xref{Forms}.
+
+The argument @var{lexical} specifies the scoping rule for local
+variables (@pxref{Variable Scoping}). If it is omitted or @code{nil},
+that means to evaluate @var{form} using the default dynamic scoping
+rule. If it is @code{t}, that means to use the lexical scoping rule.
+The value of @var{lexical} can also be a non-empty alist specifying a
+particular @dfn{lexical environment} for lexical bindings; however,
+this feature is only useful for specialized purposes, such as in Emacs
+Lisp debuggers. @xref{Lexical Binding}.
Since @code{eval} is a function, the argument expression that appears
in a call to @code{eval} is evaluated twice: once as preparation before
This limit, with the associated error when it is exceeded, is one way
Emacs Lisp avoids infinite recursion on an ill-defined function. If
you increase the value of @code{max-lisp-eval-depth} too much, such
-code can cause stack overflow instead.
+code can cause stack overflow instead. On some systems, this overflow
+can be handled. In that case, normal Lisp evaluation is interrupted
+and control is transferred back to the top level command loop
+(@code{top-level}). Note that there is no way to enter Emacs Lisp
+debugger in this situation. @xref{Error Debugging}.
+
@cindex Lisp nesting error
The depth limit counts internal uses of @code{eval}, @code{apply}, and