@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-2014 Free Software Foundation,
+@c Inc.
@c See the file elisp.texi for copying conditions.
-@setfilename ../../info/eval
-@node Evaluation, Control Structures, Symbols, Top
+@node Evaluation
@chapter Evaluation
@cindex evaluation
@cindex interpreter
@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
@dfn{form} (or an @dfn{expression}). How Emacs evaluates a form
depends on its data type. Emacs has three different kinds of form
that are evaluated differently: symbols, lists, and ``all other
-types.'' This section describes all three kinds, one by one, starting
+types''. This section describes all three kinds, one by one, starting
with the ``all other types'' which are self-evaluating forms.
@menu
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}.
-@smallexample
+@example
@group
;; @r{Build this function cell linkage:}
;; ------------- ----- ------- -------
;; | #<subr car> | <-- | car | <-- | first | <-- | erste |
;; ------------- ----- ------- -------
@end group
-@end smallexample
-
-@smallexample
@group
(symbol-function 'car)
@result{} #<subr car>
(erste '(1 2 3)) ; @r{Call the function referenced by @code{erste}.}
@result{} 1
@end group
-@end smallexample
+@end example
By contrast, the following example calls a function without any symbol
function indirection, because the first element is an anonymous Lisp
function, not a symbol.
-@smallexample
+@example
@group
((lambda (arg) (erste arg))
'(1 2 3))
@result{} 1
@end group
-@end smallexample
+@end example
@noindent
Executing the function itself evaluates its body; this does involve
symbol function indirection when calling @code{erste}.
+ This form is rarely used and is now deprecated. Instead, you should write it
+as:
+
+@example
+@group
+(funcall (lambda (arg) (erste arg))
+ '(1 2 3))
+@end group
+@end example
+or just
+@example
+@group
+(let ((arg '(1 2 3))) (erste arg))
+@end group
+@end example
+
The built-in function @code{indirect-function} provides an easy way to
perform symbol function indirection explicitly.
Here is how you could define @code{indirect-function} in Lisp:
-@smallexample
+@example
(defun indirect-function (function)
(if (symbolp function)
(indirect-function (symbol-function function))
function))
-@end smallexample
+@end example
@end defun
@node Function Forms
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