liberte@M.CS.UIUC.EDU (Daniel LaLiberte) (02/10/89)
Here is the latest version of the Evaluation chapter. It needs
more work: look for !! and ??. Many of these points are obscure
or debatable, so post to the list. Thanks.
Dan LaLiberte
uiucdcs!liberte
liberte@cs.uiuc.edu
liberte%a.cs.uiuc.edu@uiucvmd.bitnet
============
@node Evaluation
@chapter Evaluation
Since Emacs Lisp is an interpreted language, evaluation takes
the place of compiling, linking, and running in other languages.
The @dfn{evaluation} of objects in Emacs Lisp invokes the @dfn{Lisp
interpreter}. But rather than say that objects are evaluated, we say
@dfn{forms} are evaluated. This is to emphasize the view of objects as
code, rather than as data. Conversly, any piece of code in Lisp, i.e.,
an action to be performed, may also be manipulated as a piece of data.
This is one of the fundamental differences between Lisp and most other
programming languages.
An Emacs Lisp program consists of a sequence of forms.
The evaluation of forms must take place in a context. This context is
called the @dfn{environment}. It consists of the set of global symbols
and the function call stack. The @dfn{call stack} is simply a list of
stack frames, one for each nested function call.
(What about let bindings?? Is "call stack" the appropriate term?)
A @dfn{stack frame}
contains, among other things, a list of bindings local to that function.
(Variable bindings are described in @pxref{Local Variables}).
The environment also includes many other internal objects that are not
directly accessible to Emacs Lisp, but they may often be affected when
the appropriate primitive functions are called.
Naturally, many forms change the environment as a result of evaluating
them (e.g., a new symbol may be created); these forms are said to
produce @dfn{side-effects}.
Evaluation of one particular function call, @code{byte-code}, invokes
the @dfn{byte-code interpreter} on its arguments. The byte-code interpreter
uses the same environment as the Lisp interpreter, and may invoke the
Lisp interpreter. @xref{Byte Compilation} for the details.
@node Eval, Forms, , Evaluation
@section Eval
The functions and variables described in this section call the evaluator
and define limits on the evaluation process itself. Explicit evaluation
is also performed by @code{apply} and @code{funcall} (@pxref{Function
Invocation}). The details of what evaluation means for each kind of
form are described later; @pxref{Forms}.
@defun eval form
This is the basic function that performs evaluation. It evaluates
@var{form} in the current environment, and returns the result. Since
@code{eval} is a function, the argument is evaluated twice: once when
the arguments of the function call are evaluated, and again by the @code{eval}
function itself. The example illustrates this.
@example
(setq foo 'bar)
@arrow bar
(setq bar 'baz)
@arrow baz
(eval foo)
@arrow baz
@end example
@end defun
@defcmd eval-current-buffer &optional stream
This built-in function evaluates the forms in the current buffer.
@code{eval} is called repeatedly on successive forms until either the
end of the buffer is reached or an error is signaled that is not
handled.
If @var{stream} is supplied, it is bound to
@code{standard-output} (@pxref{standard-output}) during the evaluation.
@code{eval-current-buffer} always returns @code{nil}.
@end defcmd
@defcmd eval-region start end &optional stream
This built-in function evaluates forms in the current buffer in the
region defined by the positions @var{start} and @var{end}. @code{eval}
is called repeatedly on successive forms in the region until either the
end of the region is reached, or an error is signaled that is not
handled.
If @var{stream} is supplied, it is bound to
@code{standard-output} during the evaluation.
@code{eval-region} always returns @code{nil}.
@end defcmd
@defvar max-specpdl-size
This variable defines the limit on the number of Lisp variable
bindings and @code{unwind-protect}s (@pxref{unwind-protect}) that are
allowed before the error @code{error} is signaled (with data @code{"Variable
binding depth exceeds max-specpdl-size"}). This is one way that Lisp
avoids infinite recursion on an ill-defined function.
The default value is 600.
@end defvar
@defvar max-lisp-eval-depth
This built-in (does this matter??) variable defines the maximum depth
allowed in calls to @code{eval}, @code{apply}, and @code{funcall} before
the error @code{error} is signaled (with data @code{"Lisp nesting
exceeds max-lisp-eval-depth"}). @code{eval} is called recursively to
evaluate the arguments of Lisp function calls. This is one way that
Lisp avoids infinite recursion on an ill-defined function.
The default value is 200. If you set it to a value less than 100, Lisp will
reset it to 100.
@end defvar
@defvar values
The value of this variable is a list of values returned by all
expressions which were read, evaluated and printed. (how long can the
list be??) The order is reverse chronological.
(What is the use or purpose of values?? How does it relate to
the debugger??)
@example
(setq x 1)
@Arrow 1
(list 'A (1+ 2) selective-display-ellipses)
@Arrow (A 3 t)
values
@Arrow ((A 3 t) 1 ...)
@end example
@end defvar
@node Forms, Special Forms, Eval, Evaluation
@section Forms
As mentioned in the previous section, a @dfn{form} is any Lisp object.
It is important to distinguish between the text representation of a form
and the form which results from reading that text. The read syntax of
Lisp objects is described in @pxref{Read Syntax and Print
Representation} and the most basic function for reading forms is
described in @pxref{read}. The point is, forms are not evaluated
@emph{when} they are read; rather, they may be evaluated @emph{after}
they have been read.
We have three kinds of forms to consider: symbols, lists, and all
other types. The details of evaluation depend on the type. We now
consider each of these, starting with the ``all other types'' which
are called self-evaluating forms.
@node Self-Evaluating Forms, Symbol Forms, , Forms
@subsection Self-Evaluating Forms
A @dfn{self-evaluating form} is any form that is not a list or symbol.
Self-evaluating forms evaluate to their internal representation, i.e.,
themselves. In particular, evaluation of a vector does not cause
evaluation of the elements of the vector.
In these examples, the function @code{eval} (@pxref{eval}) is used to
explicitly evaluate a form that has been read but not evaluated. The
special form @code{quote} (@pxref{quote}) is used to return
(but @emph{not} evaluate) the form that follows it.
Note the examples themselves are lists, so you actually need to know
something about how lists are evaluated to fully understand them.
@xref{List Forms}. All the examples prove is that, indeed, some forms
evaluate to themselves.
@example
123
@arrow 123
(eval '123)
@arrow 123
(eval (eval '123))
@arrow 123
(eval '[(1+ 2) 3])
@arrow [(1+ 2) 3]
@end example
If you are new to Emacs Lisp, skip the rest of this section.
It is common to evaluate numbers, characters, strings, and
vectors by writing them in Lisp code. It is quite
unusual, but still possible, to evaluate any other Lisp object, even those
without a read syntax. For example,
the way to evaluate a buffer object is to build a form
with a reference to a buffer in it and then evaluate the form.
@example
(setq buf (list 'print (current-buffer)))
@arrow (print #<buffer evaluation.texinfo>)
(eval buf)
@Arrow #<buffer evaluation.texinfo>)
@arrow #<buffer evaluation.texinfo>)
@end example
@node Symbol Forms, List Forms, Self-Evaluating Forms, Forms
@subsection Symbol Forms
In this section, we are concerned with the use of symbols as
variables. When a symbol (not a quoted symbol) is evaluated, it is
treated as a variable. Emacs Lisp has two special symbols, @code{nil}
and @code{t}, that always evaluate to themselves. These symbols cannot be
rebound, nor can their value cells be changed. An attempt to change the
value results in a @code{setting-constant} error.
@findex setting-constant
@cindex setting constants
@cindex constants
Variable lookup involves several steps. (This is entirely redundant with
the Variables chapter!!) First the call stack is examined, innermost
frame first, for a binding of the symbol. If a binding for the symbol is
found, the value in the binding is returned as the result of the
evaluation; the stack is not examined further for another binding. (For
a special case see @code{makunbound} in @pxref{Binding Local
Variables}.)
If the stack has no binding for the symbol, the value cell of the
symbol is examined. (@xref{Symbol Type} for an overview of the
composition of symbol objects.) If the value cell is not void, it is
returned as the result of the evaluation. If it is void, then the error
@code{void-variable} is signaled.
@findex void-variable
@cindex void variable
(@xref{Variables} for more information
on the binding of variables.)
The example shows the value cell of a symbol being set to a value
(with @code{setq}), and then that value is returned as the result of
evaluating the symbol (since no stack frame exists with that symbol
bound)
@example
(setq a 123)
@arrow 123
(eval 'a)
@arrow 123
a
@arrow 123
@end example
@node List Forms, , Symbol Forms, Forms
@subsection List Forms
The first step in evaluating a list is examining its first element.
(The empty list, which has no elements, is evaluated as the symbol
@code{nil}.) The first element of the list should reference one of the
following objects: a primitive function, a Lisp function, a Lisp macro,
or an autoload object. By "reference" we mean that a symbol may appear
that is associated with the object, as explained below. However, after
this explanation, for simplicity we will say that the first element of
the list @emph{is} one of these objects.
Note that the first element of the list is @emph{not} evaluated,
as it is in some Lisp-like languages (e.g. Scheme).
If the first element of the list is a symbol, as it most commonly is,
then the symbol's function cell is examined. If the object referenced
by the function cell is another symbol, the function cell of that symbol
is examined, and used exactly as if it had been the original symbol.
This process, called @dfn{symbol indirection dereferencing}, continues
until a non-symbol is found, and that object is called the @dfn{function
definition} of all the symbols found along the way. But if a void
function cell is encountered, the error @code{void-function} is
signaled.
@findex void-function
@cindex void function
(One possible consequence of this process is an infinite loop, if a
symbol's function cell refers to the same symbol.)
If the first element of the list form is not a symbol, it may be a
primitive function, Lisp function, Lisp macro, or autoload object. This
object is used the same as if it had been found by the above
dereferencing process.
Once the symbol's function cell is finally dereferenced to an object
that is not a symbol, it should be a primitive function, a Lisp
function, a Lisp macro, or an autoload object. If any other kind of
object is found, the error @code{invalid-function} is signaled.
@findex invalid-function
@xref{autoload} to find out how autoloading is done.
Which object is found determines whether the rest of the elements in the
list are evaluated. For a Lisp function, all the elements are evaluated
immediately. But for a Lisp macro or primitive function, the rest of
the elements are not necessarily evaluated. See the following sections
for the details.
This example illustrates the dereferencing process.
@code{fset} (@pxref{fset}) is used to set the
function cell of a symbol and @code{symbol-function}
(@pxref{symbol-function}) is used to get the function cell of a symbol.
The symbol @code{car} is entered into the function cell of @code{first},
and the symbol @code{first} is entered into the function cell of
@code{erste}.
@example
; Build this function cell linkage:
; --------------- ------- --------- ---------
; | #<subr car> | <-- | car | <-- | first | <-- | erste |
; --------------- ------- --------- ---------
(symbol-function 'car)
@Arrow #<subr car>
(fset 'first 'car)
@Arrow car
(fset 'erste 'first)
@Arrow first
(erste '(1 2 3)) ; call the function referenced by erste
@Arrow 1
((lambda (arg)
(erste arg)) '(1 2 3)) ; call an anonymous Lisp function
@Arrow 1
@end example
@node Lisp Function Evaluation, Macro Evaluation, , List Forms
@subsubsection Lisp Function Evaluation
If the first element of a list being evaluated is a Lisp function
object, then that form is called a @dfn{Lisp function call}, or simply a
@dfn{function call}. @xref{Lambda Expressions} for the complete
description of Emacs Lisp functions.
When a function call is evaluated, first the elements of the rest of
the list are evaluated in the order they appear. Next, they are bound
to the formal arguments of the function (@pxref{Local Variables} and
@pxref{Lambda Expressions} for a complete description of the binding
process). Last, the elements of the function body are evaluated, as if
it were a @code{progn}, and the result of the function call is the value
of the last element.
Since the actual arguments are evaluated in order, you could rely on
this fact to produce side effects. This is poor programming style;
instead, you should use an explicit sequential execution construct, such
as @code{progn}. The two examples below produce the same results; the
second one is far more readable.
@example
(list (setq x 1) (nth x '(cat rat mat)))
@arrow (1 rat)
(progn (setq x 1)
(list x (nth x '(cat rat mat))))
@arrow (1 rat)
@end example
@node Lisp Macro Evalation, Primitive Function Evaluation, Lisp Function Evaluation, List Forms
@subsubsection Lisp Macro Evaluation
If the first element of a list being evaluated is a macro object, then
that form is called a @dfn{macro call}. @xref{Macros} for the complete
description of Emacs Lisp macros.
When a macro call is evaluated, the elements of the rest of the list
are @emph{not} initially evaluated; instead, they are bound to the
formal arguments of the macro (@pxref{Macros} and @pxref{Lambda
Expressions} for how this binding is done). Then the body of the macro is
evaluated and the result is a new form, called the @dfn{macro
expansion}. The macro expansion is then evaluated to produce the end
result of the marco call. Since the macro expansion is evaluated, if it
is itself another macro call, the process will be repeated. This
recursive macro expansion continues until @code{max-lisp-eval-depth}
(@pxref{max-lisp-eval-depth} is exceeded.
To repeat, actual arguments to a macro are @emph{not} evaluated when
the macro is called, but only if the macro body evaluates them explicitly, or
if they are evaluated when the macro expansion is evaluated. This
is the primary difference between functions and macros.
@node
@subsubsection Primitive Function Evaluation
If the first element of a list being evaluated is a primitive function
object, then that form is called a @dfn{primitive function call}.
When a primitive function call is evaluated, the elements of the rest
of the list are bound, @emph{unevaluated}, to the arguments of the
primitive function. Then the primitive function is executed.
It so happens that any primitive function which is not a special form
@emph{does}, in fact, evaluate all its arguments. Since primitive
function calls that are not special forms behave identically to Lisp
function calls, they are all simply called @dfn{function calls}.
@node Special Forms, Definitions and Declarations, Forms, Evaluation
@section Special Forms
A primitive function call that does not necessarily evaluate all its
arguments is known, instead, as a @dfn{special form}. Special forms define
control structures or perform variable bindings which cannot be
implemented via functions or macros (efficiently or, in some cases, at all).
The evaluation of special forms proceeds as with primitive function calls.
It is the function itself that is special, not the evaluation thereof!
@quotation
@cindex Common Lisp, special forms
@b{Common Lisp Note:} Here are some comparisons of special forms in
GNU Emacs Lisp and Common Lisp: @cindex 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 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).
@end quotation
Here is a list, in alphabetical order, of all of the special forms in
Emacs Lisp with a reference to where each is described.
@table @code
@item and
@pxref{and}
@item catch
@pxref{catch}
@item cond
@pxref{cond}
@item condition-case
@pxref{condition-case}
@item defconst
@pxref{defconst}
@item defmacro
@pxref{defmacro}
@item defun
@pxref{defun}
@item defvar
@pxref{defvar}
@item if
@pxref{if}
@item function
@pxref{function}
@item interactive
@pxref{interactive}
@item let
@pxref{let}
@item let*
@pxref{let*}
@item or
@pxref{or}
@item progn
@pxref{progn}
@item prog1
@pxref{prog1}
@item prog2
@pxref{prog2}
@item quote
@pxref{quote}
@item save-excursion
@pxref{save-excursion}
@item save-restriction
@pxref{save-restriction}
@item save-window-excursion
@pxref{save-window-excursion}
@item setq
@pxref{setq}
@item setq-default
@pxref{setq-default}
@item unwind-protect
@pxref{unwind-protect}
@item while
@pxref{while}
@item with-output-to-temp-buffer
@pxref{with-output-to-temp-buffer}
@end table
@node Identity, , Special Forms, Evaluation
@section Identity and Quoting
@cindex identity
@cindex quoting
The function @code{identity} and the special forms @code{quote} and
@code{function} return their single argument ``unchanged''. They differ
in whether they evaluate their argument (that's why they're described
here).
@c we shouldnt refer to chapter and section since info doesnt see them.
For the description of @code{function} @pxref{function}.
@defun identity object
This function returns @var{object} unchanged. But @var{object} is evaluated
when @code{function} is called.
@end defun
@defspec quote object
This special form returns @var{object}, without evaluating it. This
allows symbols and lists, which would normally be evaluated, to be
included literally in a program. (Note: It is not necessary to quote vectors
since they always evaluate to themselves.) Use @code{function} instead
of @code{quote} when quoting lambda expressions (@pxref{function}).
Because @code{quote} is used so often in programs, a convenient read
syntax is defined. An apostrophe character (@samp{@code{'}}) followed
by a form expands to a list whose first element is
@code{quote}, and whose second element is the form.
@example (quote (+ 1 2))
@Arrow (+ 1 2)
(quote foo)
@Arrow foo
'foo
@Arrow foo
''foo
@Arrow (quote foo)
['foo]
@Arrow [(quote foo)]
"'foo"
@Arrow "'foo"
@end example
@end defspecduff%eraserhead%steinmetz@UUNET.UU.NET (David A Duff) (02/11/89)
Dan,
Here some input. I'd say this is still a little rough. I've given some
suggestions, but you'll have to sort of smooth things over a bit if/after you
insert some of my stuff.
Once again, my comments begin at the left margin. Your original text is
included for context. (Do you have some other way of getting corrections that
you'd prefer?)
Dave
============
@node Evaluation
@chapter Evaluation
Since Emacs Lisp is an interpreted language, evaluation takes
the place of compiling, linking, and running in other languages.
The @dfn{evaluation} of objects in Emacs Lisp invokes the @dfn{Lisp
interpreter}.
I suppose there are a number of ways that you could explain this, but I think
the simplest would be to say that the eval function IS the interpretter.
Also, evaluation doesn't really take the place of compilation in emacs lisp.
There is a separate (though always optional) compilation phase, so it's not
really accurate to say that evaluation "takes the place of" compilation.
How about this:
In most other programming languages, a program is usually thought of a string
of text. This string of text must be parsed into some sort of machine
readable form by a process called compilation. Typically, a number of
separate program units require some type of "linking" process to combine them
into one executable file, which is then run.
In Lisp, on the other hand, a program is a lisp object (@xref{objects} [or
whatever...]). We usually call lisp objects that are used as programs
@dfn{forms} to distinguish them from lisp objects which are treated as data.
To "run" a program in emacs lisp, we call the @code{eval} function on a form.
The process performed by the @code{eval} function is called -- naturally --
@dfn{evaluation} and is the subject of this chapter. A description of
@code{eval} essentially defines the semantics of the Emacs Lisp language.
But rather than say that objects are evaluated, we say
@dfn{forms} are evaluated. This is to emphasize the view of objects as
code, rather than as data. Conversly, any piece of code in Lisp, i.e.,
an action to be performed, may also be manipulated as a piece of data.
This is one of the fundamental differences between Lisp and most other
programming languages.
An Emacs Lisp program consists of a sequence of forms.
The evaluation of forms must take place in a context. This context is
called the @dfn{environment}.
ok so far...
It consists of the set of global symbols
and the function call stack. The @dfn{call stack} is simply a list of
stack frames, one for each nested function call.
(What about let bindings?? Is "call stack" the appropriate term?)
A @dfn{stack frame}
contains, among other things, a list of bindings local to that function.
(Variable bindings are described in @pxref{Local Variables}).
Well, I don't like this stack frame business and it sounds like you don't
either. How about this:
Eval is a recursive function. The evaluation of a form can affect the results
of subsequent calls to eval by either binding the values symbols (variables),
creating new bindings for variables, and by affecting the flow of control in
the program (@xref{...} [refer to non-local exits -- e.g. catch, throw,
unwind- protect, etc.]).
[then we'd need a short section on variables and binding. I won't go into
this now, but I think it deserves a separate subsection, if for no other
reason than to make it clear to people who think they know lisp (e.g. common
lisp), that emacs lisp only has dynamic (as opposed to lexical) binding.]
The environment also includes many other internal objects that are not
directly accessible to Emacs Lisp, but they may often be affected when
the appropriate primitive functions are called.
I haven't any idea what you're referring to here. If they aren't accessible
to emacs lisp, then what's the point of mentioning them here? Oh... maybe you
are referring to control-flow type stuff (unwind-protects, and the like)?
Naturally, many forms change the environment as a result of evaluating
them (e.g., a new symbol may be created); these forms are said to
produce @dfn{side-effects}.
Evaluation of one particular function call, @code{byte-code}, invokes
the @dfn{byte-code interpreter} on its arguments. The byte-code interpreter
uses the same environment as the Lisp interpreter, and may invoke the
Lisp interpreter. @xref{Byte Compilation} for the details.
I wouldn't mention this yet. This is a side issue. Wait until we get the
basics down first.
@node Eval, Forms, , Evaluation
@section Eval
The functions and variables described in this section call the evaluator
and define limits on the evaluation process itself. Explicit evaluation
is also performed by @code{apply} and @code{funcall} (@pxref{Function
Invocation}).
What do you mean "explicit"? I think you must mean "implicit", right?
The details of what evaluation means for each kind of
form are described later; @pxref{Forms}.
@defun eval form
This is the basic function that performs evaluation. It evaluates
@var{form} in the current environment, and returns the result. Since
@code{eval} is a function, the argument is evaluated twice: once when
the arguments of the function call are evaluated, and again by the @code{eval}
function itself. The example illustrates this.
@example
(setq foo 'bar)
@arrow bar
(setq bar 'baz)
@arrow baz
(eval foo)
@arrow baz
@end example
@end defun
@defcmd eval-current-buffer &optional stream
This built-in function evaluates the forms in the current buffer.
@code{eval} is called repeatedly on successive forms until either the
end of the buffer is reached or an error is signaled that is not
handled.
If @var{stream} is supplied, it is bound to
@code{standard-output} (@pxref{standard-output}) during the evaluation.
@code{eval-current-buffer} always returns @code{nil}.
@end defcmd
@defcmd eval-region start end &optional stream
This built-in function evaluates forms in the current buffer in the
region defined by the positions @var{start} and @var{end}. @code{eval}
is called repeatedly on successive forms in the region until either the
end of the region is reached, or an error is signaled that is not
handled.
If @var{stream} is supplied, it is bound to
@code{standard-output} during the evaluation.
I'm quite sure that you meant to say that @code{standard-output} is bound to
@var{stream} and not vice versa. (They mean different things.)
@code{eval-region} always returns @code{nil}.
@end defcmd
[...]
@node List Forms, , Symbol Forms, Forms
@subsection List Forms
The first step in evaluating a list is examining its first element.
(The empty list, which has no elements, is evaluated as the symbol
@code{nil}.) The first element of the list should reference one of the
following objects: a primitive function, a Lisp function, a Lisp macro,
or an autoload object. By "reference" we mean that a symbol may appear
that is associated with the object, as explained below. However, after
this explanation, for simplicity we will say that the first element of
the list @emph{is} one of these objects.
Note that the first element of the list is @emph{not} evaluated,
as it is in some Lisp-like languages (e.g. Scheme).
If the first element of the list is a symbol, as it most commonly is,
then the symbol's function cell is examined. If the object referenced
by the function cell is another symbol, the function cell of that symbol
is examined, and used exactly as if it had been the original symbol.
This process, called @dfn{symbol indirection dereferencing}, continues
until a non-symbol is found, and that object is called the @dfn{function
definition} of all the symbols found along the way. But if a void
function cell is encountered, the error @code{void-function} is
signaled.
@findex void-function
@cindex void function
(One possible consequence of this process is an infinite loop, if a
symbol's function cell refers to the same symbol.)
this is all fine, except that we seem to be spending a lot of words on a
relatively obscure concept before we even understand the basics...
If the first element of the list form is not a symbol, it may be a
primitive function, Lisp function, Lisp macro, or autoload object. This
object is used the same as if it had been found by the above
dereferencing process.
Do you, perhaps, want to xref the sections on these objects from the OBJECTS
chapter?
Once the symbol's function cell is finally dereferenced to an object
that is not a symbol, it should be a primitive function, a Lisp
function, a Lisp macro, or an autoload object.
This is confusing, since we didn't necessarily start with a symbol -- we might
have had an actual function object. this will need a little polishing up to
make it flow together better.
If any other kind of
object is found, the error @code{invalid-function} is signaled.
@findex invalid-function
@xref{autoload} to find out how autoloading is done.
Which object is found determines whether the rest of the elements in the
list are evaluated.
"Which object" ==> "Which type of object"
For a Lisp function, all the elements are evaluated
immediately.
I'd make it explicit that this is a recursive call to eval, by saying:
If the object is a function, then the eval function is called recursively on
all of the rest of the elements in the list.
But for a Lisp macro or primitive function, the rest of
the elements are not necessarily evaluated. See the following sections
for the details.
[...]
When a function call is evaluated, first the elements of the rest of
the list are evaluated in the order they appear. Next, they are bound
to the formal arguments of the function (@pxref{Local Variables} and
@pxref{Lambda Expressions} for a complete description of the binding
process). Last, the elements of the function body are evaluated, as if
it were a @code{progn}, and the result of the function call is the value
of the last element.
Well, there's little point in saying "as though it were a progn" if you're
going to say that they're evaluated in order and the last result is returned,
anyway. The progn bit is not likely to be informative to people who are
reading this.
Since the actual arguments are evaluated in order, you could rely on
this fact to produce side effects. This is poor programming style;
instead, you should use an explicit sequential execution construct, such
as @code{progn}. The two examples below produce the same results; the
second one is far more readable.
@example
(list (setq x 1) (nth x '(cat rat mat)))
@arrow (1 rat)
(progn (setq x 1)
(list x (nth x '(cat rat mat))))
@arrow (1 rat)
@end example
@node Lisp Macro Evalation, Primitive Function Evaluation, Lisp Function Evaluation, List Forms
@subsubsection Lisp Macro Evaluation
If the first element of a list being evaluated is a macro object, then
that form is called a @dfn{macro call}. @xref{Macros} for the complete
description of Emacs Lisp macros.
When a macro call is evaluated, the elements of the rest of the list
are @emph{not} initially evaluated; instead, they are bound to the
formal arguments of the macro (@pxref{Macros} and @pxref{Lambda
Expressions} for how this binding is done). Then the body of the macro is
evaluated and the result is a new form, called the @dfn{macro
expansion}. The macro expansion is then evaluated to produce the end
result of the marco call. Since the macro expansion is evaluated, if it
is itself another macro call, the process will be repeated. This
recursive macro expansion continues until @code{max-lisp-eval-depth}
(@pxref{max-lisp-eval-depth} is exceeded.
To repeat, actual arguments to a macro are @emph{not} evaluated when
the macro is called, but only if the macro body evaluates them explicitly, or
if they are evaluated when the macro expansion is evaluated. This
is the primary difference between functions and macros.
@node
@subsubsection Primitive Function Evaluation
Looks like you're missing some information here.
[...]
@defun identity object
This function returns @var{object} unchanged. But @var{object} is evaluated
when @code{function} is called.
@end defun
I'm very confused as to why identity should appear here. It is not a special
form. It is a function.
@defspec quote object
This special form returns @var{object}, without evaluating it. This
allows symbols and lists, which would normally be evaluated, to be
included literally in a program. (Note: It is not necessary to quote vectors
since they always evaluate to themselves.) Use @code{function} instead
of @code{quote} when quoting lambda expressions (@pxref{function}).
Because @code{quote} is used so often in programs, a convenient read
syntax is defined. An apostrophe character (@samp{@code{'}}) followed
by a form expands to a list whose first element is
@code{quote}, and whose second element is the form.
Why is quote described here, while all of the other special forms are
(apparently) described somewhere else?
[...]cracraft@VENERA.ISI.EDU (Stuart Cracraft) (02/12/89)
Hi, Can you please send me the complete emacs lisp manual formatted for a regular terminal screen (e.g. so that the @dfn and @xref, and all the other texinfo things are turned into something readable) ? I'd like to read a whole copy of what currently exists before commenting. Stuart