Commit | Line | Data |
---|---|---|
b8d4c8d0 GM |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
ba318903 | 3 | @c Copyright (C) 1990-1994, 1998, 2001-2014 Free Software Foundation, |
ab422c4d | 4 | @c Inc. |
b8d4c8d0 | 5 | @c See the file elisp.texi for copying conditions. |
ecc6530d | 6 | @node Evaluation |
b8d4c8d0 GM |
7 | @chapter Evaluation |
8 | @cindex evaluation | |
9 | @cindex interpreter | |
10 | @cindex interpreter | |
11 | @cindex value of expression | |
12 | ||
13 | The @dfn{evaluation} of expressions in Emacs Lisp is performed by the | |
14 | @dfn{Lisp interpreter}---a program that receives a Lisp object as input | |
15 | and computes its @dfn{value as an expression}. How it does this depends | |
16 | on the data type of the object, according to rules described in this | |
17 | chapter. The interpreter runs automatically to evaluate portions of | |
18 | your program, but can also be called explicitly via the Lisp primitive | |
19 | function @code{eval}. | |
20 | ||
21 | @ifnottex | |
22 | @menu | |
23 | * Intro Eval:: Evaluation in the scheme of things. | |
24 | * Forms:: How various sorts of objects are evaluated. | |
25 | * Quoting:: Avoiding evaluation (to put constants in the program). | |
03988c98 | 26 | * Backquote:: Easier construction of list structure. |
b8d4c8d0 GM |
27 | * Eval:: How to invoke the Lisp interpreter explicitly. |
28 | @end menu | |
29 | ||
30 | @node Intro Eval | |
31 | @section Introduction to Evaluation | |
32 | ||
a5b99fab CY |
33 | The Lisp interpreter, or evaluator, is the part of Emacs that |
34 | computes the value of an expression that is given to it. When a | |
35 | function written in Lisp is called, the evaluator computes the value | |
36 | of the function by evaluating the expressions in the function body. | |
37 | Thus, running any Lisp program really means running the Lisp | |
38 | interpreter. | |
b8d4c8d0 GM |
39 | @end ifnottex |
40 | ||
a5b99fab | 41 | @cindex form |
b8d4c8d0 | 42 | @cindex expression |
a037c171 | 43 | @cindex S-expression |
0a6bdaa1 | 44 | @cindex sexp |
a037c171 CY |
45 | A Lisp object that is intended for evaluation is called a @dfn{form} |
46 | or @dfn{expression}@footnote{It is sometimes also referred to as an | |
47 | @dfn{S-expression} or @dfn{sexp}, but we generally do not use this | |
48 | terminology in this manual.}. The fact that forms are data objects | |
49 | and not merely text is one of the fundamental differences between | |
50 | Lisp-like languages and typical programming languages. Any object can | |
51 | be evaluated, but in practice only numbers, symbols, lists and strings | |
52 | are evaluated very often. | |
b8d4c8d0 | 53 | |
a5b99fab CY |
54 | In subsequent sections, we will describe the details of what |
55 | evaluation means for each kind of form. | |
56 | ||
57 | It is very common to read a Lisp form and then evaluate the form, | |
58 | but reading and evaluation are separate activities, and either can be | |
59 | performed alone. Reading per se does not evaluate anything; it | |
60 | converts the printed representation of a Lisp object to the object | |
61 | itself. It is up to the caller of @code{read} to specify whether this | |
b8d4c8d0 GM |
62 | object is a form to be evaluated, or serves some entirely different |
63 | purpose. @xref{Input Functions}. | |
64 | ||
b8d4c8d0 | 65 | @cindex recursive evaluation |
a5b99fab CY |
66 | Evaluation is a recursive process, and evaluating a form often |
67 | involves evaluating parts within that form. For instance, when you | |
68 | evaluate a @dfn{function call} form such as @code{(car x)}, Emacs | |
69 | first evaluates the argument (the subform @code{x}). After evaluating | |
70 | the argument, Emacs @dfn{executes} the function (@code{car}), and if | |
71 | the function is written in Lisp, execution works by evaluating the | |
31cbea1d CY |
72 | @dfn{body} of the function (in this example, however, @code{car} is |
73 | not a Lisp function; it is a primitive function implemented in C). | |
a5b99fab CY |
74 | @xref{Functions}, for more information about functions and function |
75 | calls. | |
b8d4c8d0 GM |
76 | |
77 | @cindex environment | |
a5b99fab CY |
78 | Evaluation takes place in a context called the @dfn{environment}, |
79 | which consists of the current values and bindings of all Lisp | |
80 | variables (@pxref{Variables}).@footnote{This definition of | |
81 | ``environment'' is specifically not intended to include all the data | |
82 | that can affect the result of a program.} Whenever a form refers to a | |
83 | variable without creating a new binding for it, the variable evaluates | |
84 | to the value given by the current environment. Evaluating a form may | |
31cbea1d CY |
85 | also temporarily alter the environment by binding variables |
86 | (@pxref{Local Variables}). | |
b8d4c8d0 GM |
87 | |
88 | @cindex side effect | |
a5b99fab CY |
89 | Evaluating a form may also make changes that persist; these changes |
90 | are called @dfn{side effects}. An example of a form that produces a | |
91 | side effect is @code{(setq foo 1)}. | |
b8d4c8d0 | 92 | |
a5b99fab CY |
93 | Do not confuse evaluation with command key interpretation. The |
94 | editor command loop translates keyboard input into a command (an | |
95 | interactively callable function) using the active keymaps, and then | |
96 | uses @code{call-interactively} to execute that command. Executing the | |
97 | command usually involves evaluation, if the command is written in | |
98 | Lisp; however, this step is not considered a part of command key | |
99 | interpretation. @xref{Command Loop}. | |
b8d4c8d0 GM |
100 | |
101 | @node Forms | |
102 | @section Kinds of Forms | |
103 | ||
a037c171 CY |
104 | A Lisp object that is intended to be evaluated is called a |
105 | @dfn{form} (or an @dfn{expression}). How Emacs evaluates a form | |
106 | depends on its data type. Emacs has three different kinds of form | |
107 | that are evaluated differently: symbols, lists, and ``all other | |
16152b76 | 108 | types''. This section describes all three kinds, one by one, starting |
a037c171 | 109 | with the ``all other types'' which are self-evaluating forms. |
b8d4c8d0 GM |
110 | |
111 | @menu | |
112 | * Self-Evaluating Forms:: Forms that evaluate to themselves. | |
113 | * Symbol Forms:: Symbols evaluate as variables. | |
114 | * Classifying Lists:: How to distinguish various sorts of list forms. | |
115 | * Function Indirection:: When a symbol appears as the car of a list, | |
d24880de | 116 | we find the real function via the symbol. |
b8d4c8d0 GM |
117 | * Function Forms:: Forms that call functions. |
118 | * Macro Forms:: Forms that call macros. | |
119 | * Special Forms:: "Special forms" are idiosyncratic primitives, | |
120 | most of them extremely important. | |
121 | * Autoloading:: Functions set up to load files | |
122 | containing their real definitions. | |
123 | @end menu | |
124 | ||
125 | @node Self-Evaluating Forms | |
126 | @subsection Self-Evaluating Forms | |
127 | @cindex vector evaluation | |
128 | @cindex literal evaluation | |
129 | @cindex self-evaluating form | |
130 | ||
a5b99fab CY |
131 | A @dfn{self-evaluating form} is any form that is not a list or |
132 | symbol. Self-evaluating forms evaluate to themselves: the result of | |
133 | evaluation is the same object that was evaluated. Thus, the number 25 | |
134 | evaluates to 25, and the string @code{"foo"} evaluates to the string | |
135 | @code{"foo"}. Likewise, evaluating a vector does not cause evaluation | |
136 | of the elements of the vector---it returns the same vector with its | |
137 | contents unchanged. | |
b8d4c8d0 GM |
138 | |
139 | @example | |
140 | @group | |
141 | '123 ; @r{A number, shown without evaluation.} | |
142 | @result{} 123 | |
143 | @end group | |
144 | @group | |
145 | 123 ; @r{Evaluated as usual---result is the same.} | |
146 | @result{} 123 | |
147 | @end group | |
148 | @group | |
149 | (eval '123) ; @r{Evaluated ``by hand''---result is the same.} | |
150 | @result{} 123 | |
151 | @end group | |
152 | @group | |
153 | (eval (eval '123)) ; @r{Evaluating twice changes nothing.} | |
154 | @result{} 123 | |
155 | @end group | |
156 | @end example | |
157 | ||
158 | It is common to write numbers, characters, strings, and even vectors | |
159 | in Lisp code, taking advantage of the fact that they self-evaluate. | |
160 | However, it is quite unusual to do this for types that lack a read | |
161 | syntax, because there's no way to write them textually. It is possible | |
162 | to construct Lisp expressions containing these types by means of a Lisp | |
163 | program. Here is an example: | |
164 | ||
165 | @example | |
166 | @group | |
167 | ;; @r{Build an expression containing a buffer object.} | |
168 | (setq print-exp (list 'print (current-buffer))) | |
169 | @result{} (print #<buffer eval.texi>) | |
170 | @end group | |
171 | @group | |
172 | ;; @r{Evaluate it.} | |
173 | (eval print-exp) | |
174 | @print{} #<buffer eval.texi> | |
175 | @result{} #<buffer eval.texi> | |
176 | @end group | |
177 | @end example | |
178 | ||
179 | @node Symbol Forms | |
180 | @subsection Symbol Forms | |
181 | @cindex symbol evaluation | |
182 | ||
183 | When a symbol is evaluated, it is treated as a variable. The result | |
31cbea1d CY |
184 | is the variable's value, if it has one. If the symbol has no value as |
185 | a variable, the Lisp interpreter signals an error. For more | |
186 | information on the use of variables, see @ref{Variables}. | |
b8d4c8d0 GM |
187 | |
188 | In the following example, we set the value of a symbol with | |
189 | @code{setq}. Then we evaluate the symbol, and get back the value that | |
190 | @code{setq} stored. | |
191 | ||
192 | @example | |
193 | @group | |
194 | (setq a 123) | |
195 | @result{} 123 | |
196 | @end group | |
197 | @group | |
198 | (eval 'a) | |
199 | @result{} 123 | |
200 | @end group | |
201 | @group | |
202 | a | |
203 | @result{} 123 | |
204 | @end group | |
205 | @end example | |
206 | ||
207 | The symbols @code{nil} and @code{t} are treated specially, so that the | |
208 | value of @code{nil} is always @code{nil}, and the value of @code{t} is | |
209 | always @code{t}; you cannot set or bind them to any other values. Thus, | |
210 | these two symbols act like self-evaluating forms, even though | |
211 | @code{eval} treats them like any other symbol. A symbol whose name | |
212 | starts with @samp{:} also self-evaluates in the same way; likewise, | |
213 | its value ordinarily cannot be changed. @xref{Constant Variables}. | |
214 | ||
215 | @node Classifying Lists | |
216 | @subsection Classification of List Forms | |
217 | @cindex list form evaluation | |
218 | ||
219 | A form that is a nonempty list is either a function call, a macro | |
220 | call, or a special form, according to its first element. These three | |
221 | kinds of forms are evaluated in different ways, described below. The | |
222 | remaining list elements constitute the @dfn{arguments} for the function, | |
223 | macro, or special form. | |
224 | ||
225 | The first step in evaluating a nonempty list is to examine its first | |
226 | element. This element alone determines what kind of form the list is | |
227 | and how the rest of the list is to be processed. The first element is | |
228 | @emph{not} evaluated, as it would be in some Lisp dialects such as | |
229 | Scheme. | |
230 | ||
231 | @node Function Indirection | |
232 | @subsection Symbol Function Indirection | |
233 | @cindex symbol function indirection | |
234 | @cindex indirection for functions | |
235 | @cindex void function | |
236 | ||
a5b99fab CY |
237 | If the first element of the list is a symbol then evaluation |
238 | examines the symbol's function cell, and uses its contents instead of | |
239 | the original symbol. If the contents are another symbol, this | |
240 | process, called @dfn{symbol function indirection}, is repeated until | |
241 | it obtains a non-symbol. @xref{Function Names}, for more information | |
242 | about symbol function indirection. | |
b8d4c8d0 GM |
243 | |
244 | One possible consequence of this process is an infinite loop, in the | |
0f1d2934 CY |
245 | event that a symbol's function cell refers to the same symbol. |
246 | Otherwise, we eventually obtain a non-symbol, which ought to be a | |
247 | function or other suitable object. | |
b8d4c8d0 GM |
248 | |
249 | @kindex invalid-function | |
250 | More precisely, we should now have a Lisp function (a lambda | |
a5b99fab CY |
251 | expression), a byte-code function, a primitive function, a Lisp macro, |
252 | a special form, or an autoload object. Each of these types is a case | |
253 | described in one of the following sections. If the object is not one | |
254 | of these types, Emacs signals an @code{invalid-function} error. | |
b8d4c8d0 | 255 | |
0f1d2934 CY |
256 | The following example illustrates the symbol indirection process. |
257 | We use @code{fset} to set the function cell of a symbol and | |
b8d4c8d0 | 258 | @code{symbol-function} to get the function cell contents |
0f1d2934 CY |
259 | (@pxref{Function Cells}). Specifically, we store the symbol |
260 | @code{car} into the function cell of @code{first}, and the symbol | |
261 | @code{first} into the function cell of @code{erste}. | |
b8d4c8d0 | 262 | |
ddff3351 | 263 | @example |
b8d4c8d0 GM |
264 | @group |
265 | ;; @r{Build this function cell linkage:} | |
266 | ;; ------------- ----- ------- ------- | |
267 | ;; | #<subr car> | <-- | car | <-- | first | <-- | erste | | |
268 | ;; ------------- ----- ------- ------- | |
269 | @end group | |
b8d4c8d0 GM |
270 | @group |
271 | (symbol-function 'car) | |
272 | @result{} #<subr car> | |
273 | @end group | |
274 | @group | |
275 | (fset 'first 'car) | |
276 | @result{} car | |
277 | @end group | |
278 | @group | |
279 | (fset 'erste 'first) | |
280 | @result{} first | |
281 | @end group | |
282 | @group | |
283 | (erste '(1 2 3)) ; @r{Call the function referenced by @code{erste}.} | |
284 | @result{} 1 | |
285 | @end group | |
ddff3351 | 286 | @end example |
b8d4c8d0 GM |
287 | |
288 | By contrast, the following example calls a function without any symbol | |
289 | function indirection, because the first element is an anonymous Lisp | |
290 | function, not a symbol. | |
291 | ||
ddff3351 | 292 | @example |
b8d4c8d0 GM |
293 | @group |
294 | ((lambda (arg) (erste arg)) | |
295 | '(1 2 3)) | |
296 | @result{} 1 | |
297 | @end group | |
ddff3351 | 298 | @end example |
b8d4c8d0 GM |
299 | |
300 | @noindent | |
301 | Executing the function itself evaluates its body; this does involve | |
302 | symbol function indirection when calling @code{erste}. | |
303 | ||
88ed9e87 SM |
304 | This form is rarely used and is now deprecated. Instead, you should write it |
305 | as: | |
306 | ||
ddff3351 | 307 | @example |
88ed9e87 SM |
308 | @group |
309 | (funcall (lambda (arg) (erste arg)) | |
310 | '(1 2 3)) | |
311 | @end group | |
ddff3351 | 312 | @end example |
88ed9e87 | 313 | or just |
ddff3351 | 314 | @example |
88ed9e87 SM |
315 | @group |
316 | (let ((arg '(1 2 3))) (erste arg)) | |
317 | @end group | |
ddff3351 | 318 | @end example |
88ed9e87 | 319 | |
b8d4c8d0 GM |
320 | The built-in function @code{indirect-function} provides an easy way to |
321 | perform symbol function indirection explicitly. | |
322 | ||
323 | @c Emacs 19 feature | |
324 | @defun indirect-function function &optional noerror | |
325 | @anchor{Definition of indirect-function} | |
326 | This function returns the meaning of @var{function} as a function. If | |
327 | @var{function} is a symbol, then it finds @var{function}'s function | |
328 | definition and starts over with that value. If @var{function} is not a | |
329 | symbol, then it returns @var{function} itself. | |
330 | ||
331 | This function signals a @code{void-function} error if the final symbol | |
332 | is unbound and optional argument @var{noerror} is @code{nil} or | |
333 | omitted. Otherwise, if @var{noerror} is non-@code{nil}, it returns | |
334 | @code{nil} if the final symbol is unbound. | |
335 | ||
336 | It signals a @code{cyclic-function-indirection} error if there is a | |
337 | loop in the chain of symbols. | |
338 | ||
339 | Here is how you could define @code{indirect-function} in Lisp: | |
340 | ||
ddff3351 | 341 | @example |
b8d4c8d0 GM |
342 | (defun indirect-function (function) |
343 | (if (symbolp function) | |
344 | (indirect-function (symbol-function function)) | |
345 | function)) | |
ddff3351 | 346 | @end example |
b8d4c8d0 GM |
347 | @end defun |
348 | ||
349 | @node Function Forms | |
350 | @subsection Evaluation of Function Forms | |
351 | @cindex function form evaluation | |
352 | @cindex function call | |
353 | ||
354 | If the first element of a list being evaluated is a Lisp function | |
355 | object, byte-code object or primitive function object, then that list is | |
356 | a @dfn{function call}. For example, here is a call to the function | |
357 | @code{+}: | |
358 | ||
359 | @example | |
360 | (+ 1 x) | |
361 | @end example | |
362 | ||
363 | The first step in evaluating a function call is to evaluate the | |
364 | remaining elements of the list from left to right. The results are the | |
365 | actual argument values, one value for each list element. The next step | |
366 | is to call the function with this list of arguments, effectively using | |
367 | the function @code{apply} (@pxref{Calling Functions}). If the function | |
368 | is written in Lisp, the arguments are used to bind the argument | |
369 | variables of the function (@pxref{Lambda Expressions}); then the forms | |
370 | in the function body are evaluated in order, and the value of the last | |
371 | body form becomes the value of the function call. | |
372 | ||
373 | @node Macro Forms | |
374 | @subsection Lisp Macro Evaluation | |
375 | @cindex macro call evaluation | |
376 | ||
377 | If the first element of a list being evaluated is a macro object, then | |
378 | the list is a @dfn{macro call}. When a macro call is evaluated, the | |
379 | elements of the rest of the list are @emph{not} initially evaluated. | |
380 | Instead, these elements themselves are used as the arguments of the | |
381 | macro. The macro definition computes a replacement form, called the | |
382 | @dfn{expansion} of the macro, to be evaluated in place of the original | |
383 | form. The expansion may be any sort of form: a self-evaluating | |
384 | constant, a symbol, or a list. If the expansion is itself a macro call, | |
385 | this process of expansion repeats until some other sort of form results. | |
386 | ||
387 | Ordinary evaluation of a macro call finishes by evaluating the | |
388 | expansion. However, the macro expansion is not necessarily evaluated | |
389 | right away, or at all, because other programs also expand macro calls, | |
390 | and they may or may not evaluate the expansions. | |
391 | ||
392 | Normally, the argument expressions are not evaluated as part of | |
393 | computing the macro expansion, but instead appear as part of the | |
394 | expansion, so they are computed when the expansion is evaluated. | |
395 | ||
396 | For example, given a macro defined as follows: | |
397 | ||
398 | @example | |
399 | @group | |
400 | (defmacro cadr (x) | |
401 | (list 'car (list 'cdr x))) | |
402 | @end group | |
403 | @end example | |
404 | ||
405 | @noindent | |
406 | an expression such as @code{(cadr (assq 'handler list))} is a macro | |
407 | call, and its expansion is: | |
408 | ||
409 | @example | |
410 | (car (cdr (assq 'handler list))) | |
411 | @end example | |
412 | ||
413 | @noindent | |
414 | Note that the argument @code{(assq 'handler list)} appears in the | |
415 | expansion. | |
416 | ||
417 | @xref{Macros}, for a complete description of Emacs Lisp macros. | |
418 | ||
419 | @node Special Forms | |
420 | @subsection Special Forms | |
45e46036 EZ |
421 | @cindex special forms |
422 | @cindex evaluation of special forms | |
b8d4c8d0 GM |
423 | |
424 | A @dfn{special form} is a primitive function specially marked so that | |
425 | its arguments are not all evaluated. Most special forms define control | |
426 | structures or perform variable bindings---things which functions cannot | |
427 | do. | |
428 | ||
429 | Each special form has its own rules for which arguments are evaluated | |
430 | and which are used without evaluation. Whether a particular argument is | |
431 | evaluated may depend on the results of evaluating other arguments. | |
432 | ||
53840e55 PE |
433 | If an expression's first symbol is that of a special form, the |
434 | expression should follow the rules of that special form; otherwise, | |
435 | Emacs's behavior is not well-defined (though it will not crash). For | |
436 | example, @code{((lambda (x) x . 3) 4)} contains a subexpression that | |
437 | begins with @code{lambda} but is not a well-formed @code{lambda} | |
438 | expression, so Emacs may signal an error, or may return 3 or 4 or | |
439 | @code{nil}, or may behave in other ways. | |
440 | ||
2d778742 XF |
441 | @defun special-form-p object |
442 | This predicate tests whether its argument is a special form, and | |
443 | returns @code{t} if so, @code{nil} otherwise. | |
444 | @end defun | |
445 | ||
b8d4c8d0 GM |
446 | Here is a list, in alphabetical order, of all of the special forms in |
447 | Emacs Lisp with a reference to where each is described. | |
448 | ||
449 | @table @code | |
450 | @item and | |
451 | @pxref{Combining Conditions} | |
452 | ||
453 | @item catch | |
454 | @pxref{Catch and Throw} | |
455 | ||
456 | @item cond | |
457 | @pxref{Conditionals} | |
458 | ||
459 | @item condition-case | |
460 | @pxref{Handling Errors} | |
461 | ||
462 | @item defconst | |
463 | @pxref{Defining Variables} | |
464 | ||
b8d4c8d0 GM |
465 | @item defvar |
466 | @pxref{Defining Variables} | |
467 | ||
468 | @item function | |
469 | @pxref{Anonymous Functions} | |
470 | ||
471 | @item if | |
472 | @pxref{Conditionals} | |
473 | ||
474 | @item interactive | |
475 | @pxref{Interactive Call} | |
476 | ||
53840e55 PE |
477 | @item lambda |
478 | @pxref{Lambda Expressions} | |
479 | ||
b8d4c8d0 GM |
480 | @item let |
481 | @itemx let* | |
482 | @pxref{Local Variables} | |
483 | ||
484 | @item or | |
485 | @pxref{Combining Conditions} | |
486 | ||
487 | @item prog1 | |
488 | @itemx prog2 | |
489 | @itemx progn | |
490 | @pxref{Sequencing} | |
491 | ||
492 | @item quote | |
493 | @pxref{Quoting} | |
494 | ||
495 | @item save-current-buffer | |
496 | @pxref{Current Buffer} | |
497 | ||
498 | @item save-excursion | |
499 | @pxref{Excursions} | |
500 | ||
501 | @item save-restriction | |
502 | @pxref{Narrowing} | |
503 | ||
b8d4c8d0 GM |
504 | @item setq |
505 | @pxref{Setting Variables} | |
506 | ||
507 | @item setq-default | |
508 | @pxref{Creating Buffer-Local} | |
509 | ||
510 | @item track-mouse | |
511 | @pxref{Mouse Tracking} | |
512 | ||
513 | @item unwind-protect | |
514 | @pxref{Nonlocal Exits} | |
515 | ||
516 | @item while | |
517 | @pxref{Iteration} | |
b8d4c8d0 GM |
518 | @end table |
519 | ||
520 | @cindex CL note---special forms compared | |
521 | @quotation | |
522 | @b{Common Lisp note:} Here are some comparisons of special forms in | |
523 | GNU Emacs Lisp and Common Lisp. @code{setq}, @code{if}, and | |
524 | @code{catch} are special forms in both Emacs Lisp and Common Lisp. | |
89b2c8a1 | 525 | @code{save-excursion} is a special form in Emacs Lisp, but |
b8d4c8d0 GM |
526 | doesn't exist in Common Lisp. @code{throw} is a special form in |
527 | Common Lisp (because it must be able to throw multiple values), but it | |
528 | is a function in Emacs Lisp (which doesn't have multiple | |
76f1a3c3 | 529 | values). |
b8d4c8d0 GM |
530 | @end quotation |
531 | ||
532 | @node Autoloading | |
533 | @subsection Autoloading | |
534 | ||
535 | The @dfn{autoload} feature allows you to call a function or macro | |
536 | whose function definition has not yet been loaded into Emacs. It | |
537 | specifies which file contains the definition. When an autoload object | |
538 | appears as a symbol's function definition, calling that symbol as a | |
310a820f EZ |
539 | function automatically loads the specified file; then it calls the |
540 | real definition loaded from that file. The way to arrange for an | |
541 | autoload object to appear as a symbol's function definition is | |
542 | described in @ref{Autoload}. | |
b8d4c8d0 GM |
543 | |
544 | @node Quoting | |
545 | @section Quoting | |
546 | ||
547 | The special form @code{quote} returns its single argument, as written, | |
548 | without evaluating it. This provides a way to include constant symbols | |
549 | and lists, which are not self-evaluating objects, in a program. (It is | |
550 | not necessary to quote self-evaluating objects such as numbers, strings, | |
551 | and vectors.) | |
552 | ||
553 | @defspec quote object | |
554 | This special form returns @var{object}, without evaluating it. | |
555 | @end defspec | |
556 | ||
557 | @cindex @samp{'} for quoting | |
558 | @cindex quoting using apostrophe | |
559 | @cindex apostrophe for quoting | |
560 | Because @code{quote} is used so often in programs, Lisp provides a | |
561 | convenient read syntax for it. An apostrophe character (@samp{'}) | |
562 | followed by a Lisp object (in read syntax) expands to a list whose first | |
563 | element is @code{quote}, and whose second element is the object. Thus, | |
564 | the read syntax @code{'x} is an abbreviation for @code{(quote x)}. | |
565 | ||
566 | Here are some examples of expressions that use @code{quote}: | |
567 | ||
568 | @example | |
569 | @group | |
570 | (quote (+ 1 2)) | |
571 | @result{} (+ 1 2) | |
572 | @end group | |
573 | @group | |
574 | (quote foo) | |
575 | @result{} foo | |
576 | @end group | |
577 | @group | |
578 | 'foo | |
579 | @result{} foo | |
580 | @end group | |
581 | @group | |
582 | ''foo | |
583 | @result{} (quote foo) | |
584 | @end group | |
585 | @group | |
586 | '(quote foo) | |
587 | @result{} (quote foo) | |
588 | @end group | |
589 | @group | |
590 | ['foo] | |
591 | @result{} [(quote foo)] | |
592 | @end group | |
593 | @end example | |
594 | ||
595 | Other quoting constructs include @code{function} (@pxref{Anonymous | |
596 | Functions}), which causes an anonymous lambda expression written in Lisp | |
597 | to be compiled, and @samp{`} (@pxref{Backquote}), which is used to quote | |
598 | only part of a list, while computing and substituting other parts. | |
599 | ||
03988c98 CY |
600 | @node Backquote |
601 | @section Backquote | |
602 | @cindex backquote (list substitution) | |
603 | @cindex ` (list substitution) | |
604 | @findex ` | |
605 | ||
606 | @dfn{Backquote constructs} allow you to quote a list, but | |
607 | selectively evaluate elements of that list. In the simplest case, it | |
608 | is identical to the special form @code{quote} | |
609 | @iftex | |
610 | @end iftex | |
611 | @ifnottex | |
612 | (described in the previous section; @pxref{Quoting}). | |
613 | @end ifnottex | |
614 | For example, these two forms yield identical results: | |
615 | ||
616 | @example | |
617 | @group | |
618 | `(a list of (+ 2 3) elements) | |
619 | @result{} (a list of (+ 2 3) elements) | |
620 | @end group | |
621 | @group | |
622 | '(a list of (+ 2 3) elements) | |
623 | @result{} (a list of (+ 2 3) elements) | |
624 | @end group | |
625 | @end example | |
626 | ||
627 | @findex , @r{(with backquote)} | |
628 | The special marker @samp{,} inside of the argument to backquote | |
629 | indicates a value that isn't constant. The Emacs Lisp evaluator | |
630 | evaluates the argument of @samp{,}, and puts the value in the list | |
631 | structure: | |
632 | ||
633 | @example | |
634 | @group | |
635 | `(a list of ,(+ 2 3) elements) | |
636 | @result{} (a list of 5 elements) | |
637 | @end group | |
638 | @end example | |
639 | ||
640 | @noindent | |
641 | Substitution with @samp{,} is allowed at deeper levels of the list | |
642 | structure also. For example: | |
643 | ||
644 | @example | |
645 | @group | |
646 | `(1 2 (3 ,(+ 4 5))) | |
647 | @result{} (1 2 (3 9)) | |
648 | @end group | |
649 | @end example | |
650 | ||
651 | @findex ,@@ @r{(with backquote)} | |
652 | @cindex splicing (with backquote) | |
653 | You can also @dfn{splice} an evaluated value into the resulting list, | |
654 | using the special marker @samp{,@@}. The elements of the spliced list | |
655 | become elements at the same level as the other elements of the resulting | |
656 | list. The equivalent code without using @samp{`} is often unreadable. | |
657 | Here are some examples: | |
658 | ||
659 | @example | |
660 | @group | |
661 | (setq some-list '(2 3)) | |
662 | @result{} (2 3) | |
663 | @end group | |
664 | @group | |
665 | (cons 1 (append some-list '(4) some-list)) | |
666 | @result{} (1 2 3 4 2 3) | |
667 | @end group | |
668 | @group | |
669 | `(1 ,@@some-list 4 ,@@some-list) | |
670 | @result{} (1 2 3 4 2 3) | |
671 | @end group | |
672 | ||
673 | @group | |
674 | (setq list '(hack foo bar)) | |
675 | @result{} (hack foo bar) | |
676 | @end group | |
677 | @group | |
678 | (cons 'use | |
679 | (cons 'the | |
680 | (cons 'words (append (cdr list) '(as elements))))) | |
681 | @result{} (use the words foo bar as elements) | |
682 | @end group | |
683 | @group | |
684 | `(use the words ,@@(cdr list) as elements) | |
685 | @result{} (use the words foo bar as elements) | |
686 | @end group | |
687 | @end example | |
688 | ||
689 | ||
b8d4c8d0 GM |
690 | @node Eval |
691 | @section Eval | |
692 | ||
693 | Most often, forms are evaluated automatically, by virtue of their | |
694 | occurrence in a program being run. On rare occasions, you may need to | |
695 | write code that evaluates a form that is computed at run time, such as | |
696 | after reading a form from text being edited or getting one from a | |
697 | property list. On these occasions, use the @code{eval} function. | |
d032d5e7 SM |
698 | Often @code{eval} is not needed and something else should be used instead. |
699 | For example, to get the value of a variable, while @code{eval} works, | |
700 | @code{symbol-value} is preferable; or rather than store expressions | |
701 | in a property list that then need to go through @code{eval}, it is better to | |
702 | store functions instead that are then passed to @code{funcall}. | |
b8d4c8d0 GM |
703 | |
704 | The functions and variables described in this section evaluate forms, | |
705 | specify limits to the evaluation process, or record recently returned | |
706 | values. Loading a file also does evaluation (@pxref{Loading}). | |
707 | ||
708 | It is generally cleaner and more flexible to store a function in a | |
709 | data structure, and call it with @code{funcall} or @code{apply}, than | |
710 | to store an expression in the data structure and evaluate it. Using | |
711 | functions provides the ability to pass information to them as | |
712 | arguments. | |
713 | ||
d032d5e7 | 714 | @defun eval form &optional lexical |
31cbea1d | 715 | This is the basic function for evaluating an expression. It evaluates |
362397ed CY |
716 | @var{form} in the current environment, and returns the result. The |
717 | type of the @var{form} object determines how it is evaluated. | |
718 | @xref{Forms}. | |
719 | ||
720 | The argument @var{lexical} specifies the scoping rule for local | |
721 | variables (@pxref{Variable Scoping}). If it is omitted or @code{nil}, | |
722 | that means to evaluate @var{form} using the default dynamic scoping | |
723 | rule. If it is @code{t}, that means to use the lexical scoping rule. | |
724 | The value of @var{lexical} can also be a non-empty alist specifying a | |
725 | particular @dfn{lexical environment} for lexical bindings; however, | |
726 | this feature is only useful for specialized purposes, such as in Emacs | |
727 | Lisp debuggers. @xref{Lexical Binding}. | |
b8d4c8d0 GM |
728 | |
729 | Since @code{eval} is a function, the argument expression that appears | |
730 | in a call to @code{eval} is evaluated twice: once as preparation before | |
731 | @code{eval} is called, and again by the @code{eval} function itself. | |
732 | Here is an example: | |
733 | ||
734 | @example | |
735 | @group | |
736 | (setq foo 'bar) | |
737 | @result{} bar | |
738 | @end group | |
739 | @group | |
740 | (setq bar 'baz) | |
741 | @result{} baz | |
742 | ;; @r{Here @code{eval} receives argument @code{foo}} | |
743 | (eval 'foo) | |
744 | @result{} bar | |
745 | ;; @r{Here @code{eval} receives argument @code{bar}, which is the value of @code{foo}} | |
746 | (eval foo) | |
747 | @result{} baz | |
748 | @end group | |
749 | @end example | |
750 | ||
751 | The number of currently active calls to @code{eval} is limited to | |
752 | @code{max-lisp-eval-depth} (see below). | |
753 | @end defun | |
754 | ||
755 | @deffn Command eval-region start end &optional stream read-function | |
756 | @anchor{Definition of eval-region} | |
757 | This function evaluates the forms in the current buffer in the region | |
758 | defined by the positions @var{start} and @var{end}. It reads forms from | |
759 | the region and calls @code{eval} on them until the end of the region is | |
760 | reached, or until an error is signaled and not handled. | |
761 | ||
762 | By default, @code{eval-region} does not produce any output. However, | |
763 | if @var{stream} is non-@code{nil}, any output produced by output | |
764 | functions (@pxref{Output Functions}), as well as the values that | |
765 | result from evaluating the expressions in the region are printed using | |
766 | @var{stream}. @xref{Output Streams}. | |
767 | ||
768 | If @var{read-function} is non-@code{nil}, it should be a function, | |
769 | which is used instead of @code{read} to read expressions one by one. | |
770 | This function is called with one argument, the stream for reading | |
771 | input. You can also use the variable @code{load-read-function} | |
772 | (@pxref{Definition of load-read-function,, How Programs Do Loading}) | |
773 | to specify this function, but it is more robust to use the | |
774 | @var{read-function} argument. | |
775 | ||
776 | @code{eval-region} does not move point. It always returns @code{nil}. | |
777 | @end deffn | |
778 | ||
779 | @cindex evaluation of buffer contents | |
780 | @deffn Command eval-buffer &optional buffer-or-name stream filename unibyte print | |
781 | This is similar to @code{eval-region}, but the arguments provide | |
782 | different optional features. @code{eval-buffer} operates on the | |
783 | entire accessible portion of buffer @var{buffer-or-name}. | |
784 | @var{buffer-or-name} can be a buffer, a buffer name (a string), or | |
785 | @code{nil} (or omitted), which means to use the current buffer. | |
786 | @var{stream} is used as in @code{eval-region}, unless @var{stream} is | |
787 | @code{nil} and @var{print} non-@code{nil}. In that case, values that | |
788 | result from evaluating the expressions are still discarded, but the | |
789 | output of the output functions is printed in the echo area. | |
790 | @var{filename} is the file name to use for @code{load-history} | |
791 | (@pxref{Unloading}), and defaults to @code{buffer-file-name} | |
792 | (@pxref{Buffer File Name}). If @var{unibyte} is non-@code{nil}, | |
793 | @code{read} converts strings to unibyte whenever possible. | |
794 | ||
795 | @findex eval-current-buffer | |
796 | @code{eval-current-buffer} is an alias for this command. | |
797 | @end deffn | |
798 | ||
01f17ae2 | 799 | @defopt max-lisp-eval-depth |
b8d4c8d0 GM |
800 | @anchor{Definition of max-lisp-eval-depth} |
801 | This variable defines the maximum depth allowed in calls to @code{eval}, | |
802 | @code{apply}, and @code{funcall} before an error is signaled (with error | |
803 | message @code{"Lisp nesting exceeds max-lisp-eval-depth"}). | |
804 | ||
805 | This limit, with the associated error when it is exceeded, is one way | |
806 | Emacs Lisp avoids infinite recursion on an ill-defined function. If | |
807 | you increase the value of @code{max-lisp-eval-depth} too much, such | |
808 | code can cause stack overflow instead. | |
809 | @cindex Lisp nesting error | |
810 | ||
811 | The depth limit counts internal uses of @code{eval}, @code{apply}, and | |
812 | @code{funcall}, such as for calling the functions mentioned in Lisp | |
813 | expressions, and recursive evaluation of function call arguments and | |
814 | function body forms, as well as explicit calls in Lisp code. | |
815 | ||
a5b99fab CY |
816 | The default value of this variable is 400. If you set it to a value |
817 | less than 100, Lisp will reset it to 100 if the given value is | |
818 | reached. Entry to the Lisp debugger increases the value, if there is | |
819 | little room left, to make sure the debugger itself has room to | |
820 | execute. | |
b8d4c8d0 GM |
821 | |
822 | @code{max-specpdl-size} provides another limit on nesting. | |
823 | @xref{Definition of max-specpdl-size,, Local Variables}. | |
01f17ae2 | 824 | @end defopt |
b8d4c8d0 GM |
825 | |
826 | @defvar values | |
827 | The value of this variable is a list of the values returned by all the | |
828 | expressions that were read, evaluated, and printed from buffers | |
829 | (including the minibuffer) by the standard Emacs commands which do | |
830 | this. (Note that this does @emph{not} include evaluation in | |
2bb0eca1 | 831 | @file{*ielm*} buffers, nor evaluation using @kbd{C-j} in |
b8d4c8d0 GM |
832 | @code{lisp-interaction-mode}.) The elements are ordered most recent |
833 | first. | |
834 | ||
835 | @example | |
836 | @group | |
837 | (setq x 1) | |
838 | @result{} 1 | |
839 | @end group | |
840 | @group | |
841 | (list 'A (1+ 2) auto-save-default) | |
842 | @result{} (A 3 t) | |
843 | @end group | |
844 | @group | |
845 | values | |
846 | @result{} ((A 3 t) 1 @dots{}) | |
847 | @end group | |
848 | @end example | |
849 | ||
850 | This variable is useful for referring back to values of forms recently | |
851 | evaluated. It is generally a bad idea to print the value of | |
852 | @code{values} itself, since this may be very long. Instead, examine | |
853 | particular elements, like this: | |
854 | ||
855 | @example | |
856 | @group | |
857 | ;; @r{Refer to the most recent evaluation result.} | |
858 | (nth 0 values) | |
859 | @result{} (A 3 t) | |
860 | @end group | |
861 | @group | |
862 | ;; @r{That put a new element on,} | |
863 | ;; @r{so all elements move back one.} | |
864 | (nth 1 values) | |
865 | @result{} (A 3 t) | |
866 | @end group | |
867 | @group | |
868 | ;; @r{This gets the element that was next-to-most-recent} | |
869 | ;; @r{before this example.} | |
870 | (nth 3 values) | |
871 | @result{} 1 | |
872 | @end group | |
873 | @end example | |
874 | @end defvar |