[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to eval.texi
From: |
Glenn Morris |
Subject: |
[Emacs-diffs] Changes to eval.texi |
Date: |
Thu, 06 Sep 2007 04:19:49 +0000 |
CVSROOT: /sources/emacs
Module name: emacs
Changes by: Glenn Morris <gm> 07/09/06 04:19:49
Index: eval.texi
===================================================================
RCS file: eval.texi
diff -N eval.texi
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ eval.texi 6 Sep 2007 04:19:49 -0000 1.1
@@ -0,0 +1,758 @@
address@hidden -*-texinfo-*-
address@hidden This is part of the GNU Emacs Lisp Reference Manual.
address@hidden Copyright (C) 1990, 1991, 1992, 1993, 1994, 1998, 2001, 2002,
2003,
address@hidden 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
address@hidden See the file elisp.texi for copying conditions.
address@hidden ../info/eval
address@hidden Evaluation, Control Structures, Symbols, Top
address@hidden Evaluation
address@hidden evaluation
address@hidden interpreter
address@hidden interpreter
address@hidden value of expression
+
+ The @dfn{evaluation} of expressions in Emacs Lisp is performed by the
address@hidden interpreter}---a program that receives a Lisp object as input
+and computes its @dfn{value as an expression}. How it does this depends
+on the data type of the object, according to rules described in this
+chapter. The interpreter runs automatically to evaluate portions of
+your program, but can also be called explicitly via the Lisp primitive
+function @code{eval}.
+
address@hidden
address@hidden
+* Intro Eval:: Evaluation in the scheme of things.
+* Forms:: How various sorts of objects are evaluated.
+* Quoting:: Avoiding evaluation (to put constants in the program).
+* Eval:: How to invoke the Lisp interpreter explicitly.
address@hidden menu
+
address@hidden Intro Eval
address@hidden Introduction to Evaluation
+
+ The Lisp interpreter, or evaluator, is the program that computes
+the value of an expression that is given to it. When a function
+written in Lisp is called, the evaluator computes the value of the
+function by evaluating the expressions in the function body. Thus,
+running any Lisp program really means running the Lisp interpreter.
+
+ How the evaluator handles an object depends primarily on the data
+type of the object.
address@hidden ifnottex
+
address@hidden forms
address@hidden expression
+ A Lisp object that is intended for evaluation is called an
address@hidden or a @dfn{form}. The fact that expressions are data
+objects and not merely text is one of the fundamental differences
+between Lisp-like languages and typical programming languages. Any
+object can be evaluated, but in practice only numbers, symbols, lists
+and strings are evaluated very often.
+
+ It is very common to read a Lisp expression and then evaluate the
+expression, but reading and evaluation are separate activities, and
+either can be performed alone. Reading per se does not evaluate
+anything; it converts the printed representation of a Lisp object to the
+object itself. It is up to the caller of @code{read} whether this
+object is a form to be evaluated, or serves some entirely different
+purpose. @xref{Input Functions}.
+
+ Do not confuse evaluation with command key interpretation. The
+editor command loop translates keyboard input into a command (an
+interactively callable function) using the active keymaps, and then
+uses @code{call-interactively} to invoke the command. The execution of
+the command itself involves evaluation if the command is written in
+Lisp, but that is not a part of command key interpretation itself.
address@hidden Loop}.
+
address@hidden recursive evaluation
+ Evaluation is a recursive process. That is, evaluation of a form may
+call @code{eval} to evaluate parts of the form. For example, evaluation
+of a function call first evaluates each argument of the function call,
+and then evaluates each form in the function body. Consider evaluation
+of the form @code{(car x)}: the subform @code{x} must first be evaluated
+recursively, so that its value can be passed as an argument to the
+function @code{car}.
+
+ Evaluation of a function call ultimately calls the function specified
+in it. @xref{Functions}. The execution of the function may itself work
+by evaluating the function definition; or the function may be a Lisp
+primitive implemented in C, or it may be a byte-compiled function
+(@pxref{Byte Compilation}).
+
address@hidden environment
+ The evaluation of forms takes place in a context called the
address@hidden, which consists of the current values and bindings of
+all Lisp address@hidden definition of ``environment'' is
+specifically not intended to include all the data that can affect the
+result of a program.} Whenever a form refers to a variable without
+creating a new binding for it, the value of the variable's binding in
+the current environment is used. @xref{Variables}.
+
address@hidden side effect
+ Evaluation of a form may create new environments for recursive
+evaluation by binding variables (@pxref{Local Variables}). These
+environments are temporary and vanish by the time evaluation of the form
+is complete. The form may also make changes that persist; these changes
+are called @dfn{side effects}. An example of a form that produces side
+effects is @code{(setq foo 1)}.
+
+ The details of what evaluation means for each kind of form are
+described below (@pxref{Forms}).
+
address@hidden Forms
address@hidden Kinds of Forms
+
+ A Lisp object that is intended to be evaluated is called a @dfn{form}.
+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 with the ``all other types'' which are self-evaluating
+forms.
+
address@hidden
+* Self-Evaluating Forms:: Forms that evaluate to themselves.
+* Symbol Forms:: Symbols evaluate as variables.
+* Classifying Lists:: How to distinguish various sorts of list forms.
+* Function Indirection:: When a symbol appears as the car of a list,
+ we find the real function via the symbol.
+* Function Forms:: Forms that call functions.
+* Macro Forms:: Forms that call macros.
+* Special Forms:: "Special forms" are idiosyncratic primitives,
+ most of them extremely important.
+* Autoloading:: Functions set up to load files
+ containing their real definitions.
address@hidden menu
+
address@hidden Self-Evaluating Forms
address@hidden Self-Evaluating Forms
address@hidden vector evaluation
address@hidden literal evaluation
address@hidden self-evaluating form
+
+ A @dfn{self-evaluating form} is any form that is not a list or symbol.
+Self-evaluating forms evaluate to themselves: the result of evaluation
+is the same object that was evaluated. Thus, the number 25 evaluates to
+25, and the string @code{"foo"} evaluates to the string @code{"foo"}.
+Likewise, evaluation of a vector does not cause evaluation of the
+elements of the vector---it returns the same vector with its contents
+unchanged.
+
address@hidden
address@hidden
+'123 ; @r{A number, shown without evaluation.}
+ @result{} 123
address@hidden group
address@hidden
+123 ; @r{Evaluated as usual---result is the same.}
+ @result{} 123
address@hidden group
address@hidden
+(eval '123) ; @r{Evaluated ``by hand''---result is the same.}
+ @result{} 123
address@hidden group
address@hidden
+(eval (eval '123)) ; @r{Evaluating twice changes nothing.}
+ @result{} 123
address@hidden group
address@hidden example
+
+ It is common to write numbers, characters, strings, and even vectors
+in Lisp code, taking advantage of the fact that they self-evaluate.
+However, it is quite unusual to do this for types that lack a read
+syntax, because there's no way to write them textually. It is possible
+to construct Lisp expressions containing these types by means of a Lisp
+program. Here is an example:
+
address@hidden
address@hidden
+;; @r{Build an expression containing a buffer object.}
+(setq print-exp (list 'print (current-buffer)))
+ @result{} (print #<buffer eval.texi>)
address@hidden group
address@hidden
+;; @r{Evaluate it.}
+(eval print-exp)
+ @print{} #<buffer eval.texi>
+ @result{} #<buffer eval.texi>
address@hidden group
address@hidden example
+
address@hidden Symbol Forms
address@hidden Symbol Forms
address@hidden symbol evaluation
+
+ When a symbol is evaluated, it is treated as a variable. The result
+is the variable's value, if it has one. If it has none (if its value
+cell is void), an error is signaled. For more information on the use of
+variables, see @ref{Variables}.
+
+ In the following example, we set the value of a symbol with
address@hidden Then we evaluate the symbol, and get back the value that
address@hidden stored.
+
address@hidden
address@hidden
+(setq a 123)
+ @result{} 123
address@hidden group
address@hidden
+(eval 'a)
+ @result{} 123
address@hidden group
address@hidden
+a
+ @result{} 123
address@hidden group
address@hidden example
+
+ The symbols @code{nil} and @code{t} are treated specially, so that the
+value of @code{nil} is always @code{nil}, and the value of @code{t} is
+always @code{t}; you cannot set or bind them to any other values. Thus,
+these two symbols act like self-evaluating forms, even though
address@hidden treats them like any other symbol. A symbol whose name
+starts with @samp{:} also self-evaluates in the same way; likewise,
+its value ordinarily cannot be changed. @xref{Constant Variables}.
+
address@hidden Classifying Lists
address@hidden Classification of List Forms
address@hidden list form evaluation
+
+ A form that is a nonempty list is either a function call, a macro
+call, or a special form, according to its first element. These three
+kinds of forms are evaluated in different ways, described below. The
+remaining list elements constitute the @dfn{arguments} for the function,
+macro, or special form.
+
+ The first step in evaluating a nonempty list is to examine its first
+element. This element alone determines what kind of form the list is
+and how the rest of the list is to be processed. The first element is
address@hidden evaluated, as it would be in some Lisp dialects such as
+Scheme.
+
address@hidden Function Indirection
address@hidden Symbol Function Indirection
address@hidden symbol function indirection
address@hidden indirection for functions
address@hidden void function
+
+ If the first element of the list is a symbol then evaluation examines
+the symbol's function cell, and uses its contents instead of the
+original symbol. If the contents are another symbol, this process,
+called @dfn{symbol function indirection}, is repeated until it obtains a
+non-symbol. @xref{Function Names}, for more information about using a
+symbol as a name for a function stored in the function cell of the
+symbol.
+
+ 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
address@hidden 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.
+
address@hidden invalid-function
+ More precisely, we should now have a Lisp function (a lambda
+expression), a byte-code function, a primitive function, a Lisp macro, a
+special form, or an autoload object. Each of these types is a case
+described in one of the following sections. If the object is not one of
+these types, the error @code{invalid-function} is signaled.
+
+ The following example illustrates the symbol indirection process. We
+use @code{fset} to set the function cell of a symbol and
address@hidden 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}.
+
address@hidden
address@hidden
+;; @r{Build this function cell linkage:}
+;; ------------- ----- ------- -------
+;; | #<subr car> | <-- | car | <-- | first | <-- | erste |
+;; ------------- ----- ------- -------
address@hidden group
address@hidden smallexample
+
address@hidden
address@hidden
+(symbol-function 'car)
+ @result{} #<subr car>
address@hidden group
address@hidden
+(fset 'first 'car)
+ @result{} car
address@hidden group
address@hidden
+(fset 'erste 'first)
+ @result{} first
address@hidden group
address@hidden
+(erste '(1 2 3)) ; @r{Call the function referenced by @code{erste}.}
+ @result{} 1
address@hidden group
address@hidden smallexample
+
+ 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.
+
address@hidden
address@hidden
+((lambda (arg) (erste arg))
+ '(1 2 3))
+ @result{} 1
address@hidden group
address@hidden smallexample
+
address@hidden
+Executing the function itself evaluates its body; this does involve
+symbol function indirection when calling @code{erste}.
+
+ The built-in function @code{indirect-function} provides an easy way to
+perform symbol function indirection explicitly.
+
address@hidden Emacs 19 feature
address@hidden indirect-function function &optional noerror
address@hidden of indirect-function}
+This function returns the meaning of @var{function} as a function. If
address@hidden is a symbol, then it finds @var{function}'s function
+definition and starts over with that value. If @var{function} is not a
+symbol, then it returns @var{function} itself.
+
+This function signals a @code{void-function} error if the final symbol
+is unbound and optional argument @var{noerror} is @code{nil} or
+omitted. Otherwise, if @var{noerror} is address@hidden, it returns
address@hidden if the final symbol is unbound.
+
+It signals a @code{cyclic-function-indirection} error if there is a
+loop in the chain of symbols.
+
+Here is how you could define @code{indirect-function} in Lisp:
+
address@hidden
+(defun indirect-function (function)
+ (if (symbolp function)
+ (indirect-function (symbol-function function))
+ function))
address@hidden smallexample
address@hidden defun
+
address@hidden Function Forms
address@hidden Evaluation of Function Forms
address@hidden function form evaluation
address@hidden function call
+
+ If the first element of a list being evaluated is a Lisp function
+object, byte-code object or primitive function object, then that list is
+a @dfn{function call}. For example, here is a call to the function
address@hidden:
+
address@hidden
+(+ 1 x)
address@hidden example
+
+ The first step in evaluating a function call is to evaluate the
+remaining elements of the list from left to right. The results are the
+actual argument values, one value for each list element. The next step
+is to call the function with this list of arguments, effectively using
+the function @code{apply} (@pxref{Calling Functions}). If the function
+is written in Lisp, the arguments are used to bind the argument
+variables of the function (@pxref{Lambda Expressions}); then the forms
+in the function body are evaluated in order, and the value of the last
+body form becomes the value of the function call.
+
address@hidden Macro Forms
address@hidden Lisp Macro Evaluation
address@hidden macro call evaluation
+
+ If the first element of a list being evaluated is a macro object, then
+the list is a @dfn{macro call}. When a macro call is evaluated, the
+elements of the rest of the list are @emph{not} initially evaluated.
+Instead, these elements themselves are used as the arguments of the
+macro. The macro definition computes a replacement form, called the
address@hidden of the macro, to be evaluated in place of the original
+form. The expansion may be any sort of form: a self-evaluating
+constant, a symbol, or a list. If the expansion is itself a macro call,
+this process of expansion repeats until some other sort of form results.
+
+ Ordinary evaluation of a macro call finishes by evaluating the
+expansion. However, the macro expansion is not necessarily evaluated
+right away, or at all, because other programs also expand macro calls,
+and they may or may not evaluate the expansions.
+
+ Normally, the argument expressions are not evaluated as part of
+computing the macro expansion, but instead appear as part of the
+expansion, so they are computed when the expansion is evaluated.
+
+ For example, given a macro defined as follows:
+
address@hidden
address@hidden
+(defmacro cadr (x)
+ (list 'car (list 'cdr x)))
address@hidden group
address@hidden example
+
address@hidden
+an expression such as @code{(cadr (assq 'handler list))} is a macro
+call, and its expansion is:
+
address@hidden
+(car (cdr (assq 'handler list)))
address@hidden example
+
address@hidden
+Note that the argument @code{(assq 'handler list)} appears in the
+expansion.
+
address@hidden, for a complete description of Emacs Lisp macros.
+
address@hidden Special Forms
address@hidden Special Forms
address@hidden special form evaluation
+
+ A @dfn{special form} is a primitive function specially marked so that
+its arguments are not all evaluated. Most special forms define control
+structures or perform variable bindings---things which functions cannot
+do.
+
+ Each special form has its own rules for which arguments are evaluated
+and which are used without evaluation. Whether a particular argument is
+evaluated may depend on the results of evaluating other arguments.
+
+ Here is a list, in alphabetical order, of all of the special forms in
+Emacs Lisp with a reference to where each is described.
+
address@hidden @code
address@hidden and
address@hidden Conditions}
+
address@hidden catch
address@hidden and Throw}
+
address@hidden cond
address@hidden
+
address@hidden condition-case
address@hidden Errors}
+
address@hidden defconst
address@hidden Variables}
+
address@hidden defmacro
address@hidden Macros}
+
address@hidden defun
address@hidden Functions}
+
address@hidden defvar
address@hidden Variables}
+
address@hidden function
address@hidden Functions}
+
address@hidden if
address@hidden
+
address@hidden interactive
address@hidden Call}
+
address@hidden let
address@hidden let*
address@hidden Variables}
+
address@hidden or
address@hidden Conditions}
+
address@hidden prog1
address@hidden prog2
address@hidden progn
address@hidden
+
address@hidden quote
address@hidden
+
address@hidden save-current-buffer
address@hidden Buffer}
+
address@hidden save-excursion
address@hidden
+
address@hidden save-restriction
address@hidden
+
address@hidden save-window-excursion
address@hidden Configurations}
+
address@hidden setq
address@hidden Variables}
+
address@hidden setq-default
address@hidden Buffer-Local}
+
address@hidden track-mouse
address@hidden Tracking}
+
address@hidden unwind-protect
address@hidden Exits}
+
address@hidden while
address@hidden
+
address@hidden with-output-to-temp-buffer
address@hidden Displays}
address@hidden table
+
address@hidden CL note---special forms compared
address@hidden
address@hidden Lisp note:} Here are some comparisons of special forms in
+GNU Emacs Lisp and Common Lisp. @code{setq}, @code{if}, and
address@hidden are special forms in both Emacs Lisp and Common Lisp.
address@hidden is a special form in Emacs Lisp, but a macro in Common
+Lisp. @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)address@hidden
address@hidden quotation
+
address@hidden Autoloading
address@hidden Autoloading
+
+ The @dfn{autoload} feature allows you to call a function or macro
+whose function definition has not yet been loaded into Emacs. It
+specifies which file contains the definition. When an autoload object
+appears as a symbol's function definition, calling that symbol as a
+function automatically loads the specified file; then it calls the real
+definition loaded from that file. @xref{Autoload}.
+
address@hidden Quoting
address@hidden Quoting
+
+ The special form @code{quote} returns its single argument, as written,
+without evaluating it. This provides a way to include constant symbols
+and lists, which are not self-evaluating objects, in a program. (It is
+not necessary to quote self-evaluating objects such as numbers, strings,
+and vectors.)
+
address@hidden quote object
+This special form returns @var{object}, without evaluating it.
address@hidden defspec
+
address@hidden @samp{'} for quoting
address@hidden quoting using apostrophe
address@hidden apostrophe for quoting
+Because @code{quote} is used so often in programs, Lisp provides a
+convenient read syntax for it. An apostrophe character (@samp{'})
+followed by a Lisp object (in read syntax) expands to a list whose first
+element is @code{quote}, and whose second element is the object. Thus,
+the read syntax @code{'x} is an abbreviation for @code{(quote x)}.
+
+Here are some examples of expressions that use @code{quote}:
+
address@hidden
address@hidden
+(quote (+ 1 2))
+ @result{} (+ 1 2)
address@hidden group
address@hidden
+(quote foo)
+ @result{} foo
address@hidden group
address@hidden
+'foo
+ @result{} foo
address@hidden group
address@hidden
+''foo
+ @result{} (quote foo)
address@hidden group
address@hidden
+'(quote foo)
+ @result{} (quote foo)
address@hidden group
address@hidden
+['foo]
+ @result{} [(quote foo)]
address@hidden group
address@hidden example
+
+ Other quoting constructs include @code{function} (@pxref{Anonymous
+Functions}), which causes an anonymous lambda expression written in Lisp
+to be compiled, and @samp{`} (@pxref{Backquote}), which is used to quote
+only part of a list, while computing and substituting other parts.
+
address@hidden Eval
address@hidden Eval
+
+ Most often, forms are evaluated automatically, by virtue of their
+occurrence in a program being run. On rare occasions, you may need to
+write code that evaluates a form that is computed at run time, such as
+after reading a form from text being edited or getting one from a
+property list. On these occasions, use the @code{eval} function.
+
+ The functions and variables described in this section evaluate forms,
+specify limits to the evaluation process, or record recently returned
+values. Loading a file also does evaluation (@pxref{Loading}).
+
+ It is generally cleaner and more flexible to store a function in a
+data structure, and call it with @code{funcall} or @code{apply}, than
+to store an expression in the data structure and evaluate it. Using
+functions provides the ability to pass information to them as
+arguments.
+
address@hidden eval form
+This is the basic function evaluating an expression. It evaluates
address@hidden in the current environment and returns the result. How the
+evaluation proceeds depends on the type of the object (@pxref{Forms}).
+
+Since @code{eval} is a function, the argument expression that appears
+in a call to @code{eval} is evaluated twice: once as preparation before
address@hidden is called, and again by the @code{eval} function itself.
+Here is an example:
+
address@hidden
address@hidden
+(setq foo 'bar)
+ @result{} bar
address@hidden group
address@hidden
+(setq bar 'baz)
+ @result{} baz
+;; @r{Here @code{eval} receives argument @code{foo}}
+(eval 'foo)
+ @result{} bar
+;; @r{Here @code{eval} receives argument @code{bar}, which is the value of
@code{foo}}
+(eval foo)
+ @result{} baz
address@hidden group
address@hidden example
+
+The number of currently active calls to @code{eval} is limited to
address@hidden (see below).
address@hidden defun
+
address@hidden Command eval-region start end &optional stream read-function
address@hidden of eval-region}
+This function evaluates the forms in the current buffer in the region
+defined by the positions @var{start} and @var{end}. It reads forms from
+the region and calls @code{eval} on them until the end of the region is
+reached, or until an error is signaled and not handled.
+
+By default, @code{eval-region} does not produce any output. However,
+if @var{stream} is address@hidden, any output produced by output
+functions (@pxref{Output Functions}), as well as the values that
+result from evaluating the expressions in the region are printed using
address@hidden @xref{Output Streams}.
+
+If @var{read-function} is address@hidden, it should be a function,
+which is used instead of @code{read} to read expressions one by one.
+This function is called with one argument, the stream for reading
+input. You can also use the variable @code{load-read-function}
+(@pxref{Definition of load-read-function,, How Programs Do Loading})
+to specify this function, but it is more robust to use the
address@hidden argument.
+
address@hidden does not move point. It always returns @code{nil}.
address@hidden deffn
+
address@hidden evaluation of buffer contents
address@hidden Command eval-buffer &optional buffer-or-name stream filename
unibyte print
+This is similar to @code{eval-region}, but the arguments provide
+different optional features. @code{eval-buffer} operates on the
+entire accessible portion of buffer @var{buffer-or-name}.
address@hidden can be a buffer, a buffer name (a string), or
address@hidden (or omitted), which means to use the current buffer.
address@hidden is used as in @code{eval-region}, unless @var{stream} is
address@hidden and @var{print} address@hidden In that case, values that
+result from evaluating the expressions are still discarded, but the
+output of the output functions is printed in the echo area.
address@hidden is the file name to use for @code{load-history}
+(@pxref{Unloading}), and defaults to @code{buffer-file-name}
+(@pxref{Buffer File Name}). If @var{unibyte} is address@hidden,
address@hidden converts strings to unibyte whenever possible.
+
address@hidden eval-current-buffer
address@hidden is an alias for this command.
address@hidden deffn
+
address@hidden max-lisp-eval-depth
address@hidden of max-lisp-eval-depth}
+This variable defines the maximum depth allowed in calls to @code{eval},
address@hidden, and @code{funcall} before an error is signaled (with error
+message @code{"Lisp nesting exceeds max-lisp-eval-depth"}).
+
+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.
address@hidden Lisp nesting error
+
+The depth limit counts internal uses of @code{eval}, @code{apply}, and
address@hidden, such as for calling the functions mentioned in Lisp
+expressions, and recursive evaluation of function call arguments and
+function body forms, as well as explicit calls in Lisp code.
+
+The default value of this variable is 300. If you set it to a value
+less than 100, Lisp will reset it to 100 if the given value is reached.
+Entry to the Lisp debugger increases the value, if there is little room
+left, to make sure the debugger itself has room to execute.
+
address@hidden provides another limit on nesting.
address@hidden of max-specpdl-size,, Local Variables}.
address@hidden defvar
+
address@hidden values
+The value of this variable is a list of the values returned by all the
+expressions that were read, evaluated, and printed from buffers
+(including the minibuffer) by the standard Emacs commands which do
+this. (Note that this does @emph{not} include evaluation in
address@hidden buffers, nor evaluation using @kbd{C-j} in
address@hidden) The elements are ordered most recent
+first.
+
address@hidden
address@hidden
+(setq x 1)
+ @result{} 1
address@hidden group
address@hidden
+(list 'A (1+ 2) auto-save-default)
+ @result{} (A 3 t)
address@hidden group
address@hidden
+values
+ @result{} ((A 3 t) 1 @dots{})
address@hidden group
address@hidden example
+
+This variable is useful for referring back to values of forms recently
+evaluated. It is generally a bad idea to print the value of
address@hidden itself, since this may be very long. Instead, examine
+particular elements, like this:
+
address@hidden
address@hidden
+;; @r{Refer to the most recent evaluation result.}
+(nth 0 values)
+ @result{} (A 3 t)
address@hidden group
address@hidden
+;; @r{That put a new element on,}
+;; @r{so all elements move back one.}
+(nth 1 values)
+ @result{} (A 3 t)
address@hidden group
address@hidden
+;; @r{This gets the element that was next-to-most-recent}
+;; @r{before this example.}
+(nth 3 values)
+ @result{} 1
address@hidden group
address@hidden example
address@hidden defvar
+
address@hidden
+ arch-tag: f723a4e0-31b3-453f-8afc-0bf8fd276d57
address@hidden ignore