Mercurial > emacs
comparison lispref/eval.texi @ 6558:fa8ff07eaafc
Initial revision
author | Richard M. Stallman <rms@gnu.org> |
---|---|
date | Mon, 28 Mar 1994 20:21:44 +0000 |
parents | |
children | 19bd3bfc57de |
comparison
equal
deleted
inserted
replaced
6557:74758cf67338 | 6558:fa8ff07eaafc |
---|---|
1 @c -*-texinfo-*- | |
2 @c This is part of the GNU Emacs Lisp Reference Manual. | |
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. | |
4 @c See the file elisp.texi for copying conditions. | |
5 @setfilename ../info/eval | |
6 @node Evaluation, Control Structures, Symbols, Top | |
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 @ifinfo | |
22 @menu | |
23 * Intro Eval:: Evaluation in the scheme of things. | |
24 * Eval:: How to invoke the Lisp interpreter explicitly. | |
25 * Forms:: How various sorts of objects are evaluated. | |
26 * Quoting:: Avoiding evaluation (to put constants in the program). | |
27 @end menu | |
28 | |
29 @node Intro Eval | |
30 @section Introduction to Evaluation | |
31 | |
32 The Lisp interpreter, or evaluator, is the program which computes | |
33 the value of an expression which is given to it. When a function | |
34 written in Lisp is called, the evaluator computes the value of the | |
35 function by evaluating the expressions in the function body. Thus, | |
36 running any Lisp program really means running the Lisp interpreter. | |
37 | |
38 How the evaluator handles an object depends primarily on the data | |
39 type of the object. | |
40 @end ifinfo | |
41 | |
42 @cindex forms | |
43 @cindex expression | |
44 A Lisp object which is intended for evaluation is called an | |
45 @dfn{expression} or a @dfn{form}. The fact that expressions are data | |
46 objects and not merely text is one of the fundamental differences | |
47 between Lisp-like languages and typical programming languages. Any | |
48 object can be evaluated, but in practice only numbers, symbols, lists | |
49 and strings are evaluated very often. | |
50 | |
51 It is very common to read a Lisp expression and then evaluate the | |
52 expression, but reading and evaluation are separate activities, and | |
53 either can be performed alone. Reading per se does not evaluate | |
54 anything; it converts the printed representation of a Lisp object to the | |
55 object itself. It is up to the caller of @code{read} whether this | |
56 object is a form to be evaluated, or serves some entirely different | |
57 purpose. @xref{Input Functions}. | |
58 | |
59 Do not confuse evaluation with command key interpretation. The | |
60 editor command loop translates keyboard input into a command (an | |
61 interactively callable function) using the active keymaps, and then | |
62 uses @code{call-interactively} to invoke the command. The execution of | |
63 the command itself involves evaluation if the command is written in | |
64 Lisp, but that is not a part of command key interpretation itself. | |
65 @xref{Command Loop}. | |
66 | |
67 @cindex recursive evaluation | |
68 Evaluation is a recursive process. That is, evaluation of a form may | |
69 call @code{eval} to evaluate parts of the form. For example, evaluation | |
70 of a function call first evaluates each argument of the function call, | |
71 and then evaluates each form in the function body. Consider evaluation | |
72 of the form @code{(car x)}: the subform @code{x} must first be evaluated | |
73 recursively, so that its value can be passed as an argument to the | |
74 function @code{car}. | |
75 | |
76 @cindex environment | |
77 The evaluation of forms takes place in a context called the | |
78 @dfn{environment}, which consists of the current values and bindings of | |
79 all Lisp variables.@footnote{This definition of ``environment'' is | |
80 specifically not intended to include all the data which can affect the | |
81 result of a program.} Whenever the form refers to a variable without | |
82 creating a new binding for it, the value of the binding in the current | |
83 environment is used. @xref{Variables}. | |
84 | |
85 @cindex side effect | |
86 Evaluation of a form may create new environments for recursive | |
87 evaluation by binding variables (@pxref{Local Variables}). These | |
88 environments are temporary and vanish by the time evaluation of the form | |
89 is complete. The form may also make changes that persist; these changes | |
90 are called @dfn{side effects}. An example of a form that produces side | |
91 effects is @code{(setq foo 1)}. | |
92 | |
93 Finally, evaluation of one particular function call, @code{byte-code}, | |
94 invokes the @dfn{byte-code interpreter} on its arguments. Although the | |
95 byte-code interpreter is not the same as the Lisp interpreter, it uses | |
96 the same environment as the Lisp interpreter, and may on occasion invoke | |
97 the Lisp interpreter. (@xref{Byte Compilation}.) | |
98 | |
99 The details of what evaluation means for each kind of form are | |
100 described below (@pxref{Forms}). | |
101 | |
102 @node Eval | |
103 @section Eval | |
104 | |
105 Most often, forms are evaluated automatically, by virtue of their | |
106 occurrence in a program being run. On rare occasions, you may need to | |
107 write code that evaluates a form that is computed at run time, such as | |
108 after reading a form from text being edited or getting one from a | |
109 property list. On these occasions, use the @code{eval} function. | |
110 | |
111 The functions and variables described in this section evaluate | |
112 forms, specify limits to the evaluation process, or record recently | |
113 returned values. Loading a file also does evaluation | |
114 (@pxref{Loading}). | |
115 | |
116 @defun eval form | |
117 This is the basic function for performing evaluation. It evaluates | |
118 @var{form} in the current environment and returns the result. How the | |
119 evaluation proceeds depends on the type of the object (@pxref{Forms}). | |
120 | |
121 Since @code{eval} is a function, the argument expression that appears | |
122 in a call to @code{eval} is evaluated twice: once as preparation before | |
123 @code{eval} is called, and again by the @code{eval} function itself. | |
124 Here is an example: | |
125 | |
126 @example | |
127 @group | |
128 (setq foo 'bar) | |
129 @result{} bar | |
130 @end group | |
131 @group | |
132 (setq bar 'baz) | |
133 @result{} baz | |
134 ;; @r{@code{eval} receives argument @code{bar}, which is the value of @code{foo}} | |
135 (eval foo) | |
136 @result{} baz | |
137 @end group | |
138 @end example | |
139 | |
140 The number of currently active calls to @code{eval} is limited to | |
141 @code{max-lisp-eval-depth} (see below). | |
142 @end defun | |
143 | |
144 @cindex evaluation of buffer contents | |
145 @deffn Command eval-current-buffer &optional stream | |
146 This function evaluates the forms in the current buffer. It reads | |
147 forms from the buffer and calls @code{eval} on them until the end of the | |
148 buffer is reached, or until an error is signaled and not handled. | |
149 | |
150 If @var{stream} is supplied, the variable @code{standard-output} is | |
151 bound to @var{stream} during the evaluation (@pxref{Output | |
152 Functions}). | |
153 | |
154 @code{eval-current-buffer} always returns @code{nil}. | |
155 @end deffn | |
156 | |
157 @deffn Command eval-region start end &optional stream | |
158 This function evaluates the forms in the current buffer in the region | |
159 defined by the positions @var{start} and @var{end}. It reads forms from | |
160 the region and calls @code{eval} on them until the end of the region is | |
161 reached, or until an error is signaled and not handled. | |
162 | |
163 If @var{stream} is supplied, @code{standard-output} is bound to it | |
164 for the duration of the command. | |
165 | |
166 @code{eval-region} always returns @code{nil}. | |
167 @end deffn | |
168 | |
169 @defvar max-lisp-eval-depth | |
170 This variable defines the maximum depth allowed in calls to @code{eval}, | |
171 @code{apply}, and @code{funcall} before an error is signaled (with error | |
172 message @code{"Lisp nesting exceeds max-lisp-eval-depth"}). This counts | |
173 calling the functions mentioned in Lisp expression, and recursive | |
174 evaluation of function call arguments and function body forms. | |
175 | |
176 This limit, with the associated error when it is exceeded, is one way | |
177 that Lisp avoids infinite recursion on an ill-defined function. | |
178 @cindex Lisp nesting error | |
179 | |
180 The default value of this variable is 200. If you set it to a value | |
181 less than 100, Lisp will reset it to 100 if the given value is reached. | |
182 | |
183 @code{max-specpdl-size} provides another limit on nesting. | |
184 @xref{Local Variables}. | |
185 @end defvar | |
186 | |
187 @defvar values | |
188 The value of this variable is a list of the values returned by all the | |
189 expressions which were read from buffers (including the minibuffer), | |
190 evaluated, and printed. The elements are ordered most recent first. | |
191 | |
192 @example | |
193 @group | |
194 (setq x 1) | |
195 @result{} 1 | |
196 @end group | |
197 @group | |
198 (list 'A (1+ 2) auto-save-default) | |
199 @result{} (A 3 t) | |
200 @end group | |
201 @group | |
202 values | |
203 @result{} ((A 3 t) 1 @dots{}) | |
204 @end group | |
205 @end example | |
206 | |
207 This variable is useful for referring back to values of forms recently | |
208 evaluated. It is generally a bad idea to print the value of | |
209 @code{values} itself, since this may be very long. Instead, examine | |
210 particular elements, like this: | |
211 | |
212 @example | |
213 @group | |
214 ;; @r{Refer to the most recent evaluation result.} | |
215 (nth 0 values) | |
216 @result{} (A 3 t) | |
217 @end group | |
218 @group | |
219 ;; @r{That put a new element on,} | |
220 ;; @r{so all elements move back one.} | |
221 (nth 1 values) | |
222 @result{} (A 3 t) | |
223 @end group | |
224 @group | |
225 ;; @r{This gets the element that was next-to-last} | |
226 ;; @r{before this example.} | |
227 (nth 3 values) | |
228 @result{} 1 | |
229 @end group | |
230 @end example | |
231 @end defvar | |
232 | |
233 @node Forms | |
234 @section Kinds of Forms | |
235 | |
236 A Lisp object that is intended to be evaluated is called a @dfn{form}. | |
237 How Emacs evaluates a form depends on its data type. Emacs has three | |
238 different kinds of form that are evaluated differently: symbols, lists, | |
239 and ``all other types''. This section describes all three kinds, | |
240 starting with ``all other types'' which are self-evaluating forms. | |
241 | |
242 @menu | |
243 * Self-Evaluating Forms:: Forms that evaluate to themselves. | |
244 * Symbol Forms:: Symbols evaluate as variables. | |
245 * Classifying Lists:: How to distinguish various sorts of list forms. | |
246 * Function Indirection:: When a symbol appears as the car of a list, | |
247 we find the real function via the symbol. | |
248 * Function Forms:: Forms that call functions. | |
249 * Macro Forms:: Forms that call macros. | |
250 * Special Forms:: ``Special forms'' are idiosyncratic primitives, | |
251 most of them extremely important. | |
252 * Autoloading:: Functions set up to load files | |
253 containing their real definitions. | |
254 @end menu | |
255 | |
256 @node Self-Evaluating Forms | |
257 @subsection Self-Evaluating Forms | |
258 @cindex vector evaluation | |
259 @cindex literal evaluation | |
260 @cindex self-evaluating form | |
261 | |
262 A @dfn{self-evaluating form} is any form that is not a list or symbol. | |
263 Self-evaluating forms evaluate to themselves: the result of evaluation | |
264 is the same object that was evaluated. Thus, the number 25 evaluates to | |
265 25, and the string @code{"foo"} evaluates to the string @code{"foo"}. | |
266 Likewise, evaluation of a vector does not cause evaluation of the | |
267 elements of the vector---it returns the same vector with its contents | |
268 unchanged. | |
269 | |
270 @example | |
271 @group | |
272 '123 ; @r{An object, shown without evaluation.} | |
273 @result{} 123 | |
274 @end group | |
275 @group | |
276 123 ; @r{Evaluated as usual---result is the same.} | |
277 @result{} 123 | |
278 @end group | |
279 @group | |
280 (eval '123) ; @r{Evaluated ``by hand''---result is the same.} | |
281 @result{} 123 | |
282 @end group | |
283 @group | |
284 (eval (eval '123)) ; @r{Evaluating twice changes nothing.} | |
285 @result{} 123 | |
286 @end group | |
287 @end example | |
288 | |
289 It is common to write numbers, characters, strings, and even vectors | |
290 in Lisp code, taking advantage of the fact that they self-evaluate. | |
291 However, it is quite unusual to do this for types that lack a read | |
292 syntax, because there's no way to write them textually; however, it is | |
293 possible to construct Lisp expressions containing these types by means | |
294 of a Lisp program. Here is an example: | |
295 | |
296 @example | |
297 @group | |
298 ;; @r{Build an expression containing a buffer object.} | |
299 (setq buffer (list 'print (current-buffer))) | |
300 @result{} (print #<buffer eval.texi>) | |
301 @end group | |
302 @group | |
303 ;; @r{Evaluate it.} | |
304 (eval buffer) | |
305 @print{} #<buffer eval.texi> | |
306 @result{} #<buffer eval.texi> | |
307 @end group | |
308 @end example | |
309 | |
310 @node Symbol Forms | |
311 @subsection Symbol Forms | |
312 @cindex symbol evaluation | |
313 | |
314 When a symbol is evaluated, it is treated as a variable. The result | |
315 is the variable's value, if it has one. If it has none (if its value | |
316 cell is void), an error is signaled. For more information on the use of | |
317 variables, see @ref{Variables}. | |
318 | |
319 In the following example, we set the value of a symbol with | |
320 @code{setq}. Then we evaluate the symbol, and get back the value that | |
321 @code{setq} stored. | |
322 | |
323 @example | |
324 @group | |
325 (setq a 123) | |
326 @result{} 123 | |
327 @end group | |
328 @group | |
329 (eval 'a) | |
330 @result{} 123 | |
331 @end group | |
332 @group | |
333 a | |
334 @result{} 123 | |
335 @end group | |
336 @end example | |
337 | |
338 The symbols @code{nil} and @code{t} are treated specially, so that the | |
339 value of @code{nil} is always @code{nil}, and the value of @code{t} is | |
340 always @code{t}. Thus, these two symbols act like self-evaluating | |
341 forms, even though @code{eval} treats them like any other symbol. | |
342 | |
343 @node Classifying Lists | |
344 @subsection Classification of List Forms | |
345 @cindex list form evaluation | |
346 | |
347 A form that is a nonempty list is either a function call, a macro | |
348 call, or a special form, according to its first element. These three | |
349 kinds of forms are evaluated in different ways, described below. The | |
350 remaining list elements constitute the @dfn{arguments} for the function, | |
351 macro, or special form. | |
352 | |
353 The first step in evaluating a nonempty list is to examine its first | |
354 element. This element alone determines what kind of form the list is | |
355 and how the rest of the list is to be processed. The first element is | |
356 @emph{not} evaluated, as it would be in some Lisp dialects such as | |
357 Scheme. | |
358 | |
359 @node Function Indirection | |
360 @subsection Symbol Function Indirection | |
361 @cindex symbol function indirection | |
362 @cindex indirection | |
363 @cindex void function | |
364 | |
365 If the first element of the list is a symbol then evaluation examines | |
366 the symbol's function cell, and uses its contents instead of the | |
367 original symbol. If the contents are another symbol, this process, | |
368 called @dfn{symbol function indirection}, is repeated until it obtains a | |
369 non-symbol. @xref{Function Names}, for more information about using a | |
370 symbol as a name for a function stored in the function cell of the | |
371 symbol. | |
372 | |
373 One possible consequence of this process is an infinite loop, in the | |
374 event that a symbol's function cell refers to the same symbol. Or a | |
375 symbol may have a void function cell, in which case the subroutine | |
376 @code{symbol-function} signals a @code{void-function} error. But if | |
377 neither of these things happens, we eventually obtain a non-symbol, | |
378 which ought to be a function or other suitable object. | |
379 | |
380 @kindex invalid-function | |
381 @cindex invalid function | |
382 More precisely, we should now have a Lisp function (a lambda | |
383 expression), a byte-code function, a primitive function, a Lisp macro, a | |
384 special form, or an autoload object. Each of these types is a case | |
385 described in one of the following sections. If the object is not one of | |
386 these types, the error @code{invalid-function} is signaled. | |
387 | |
388 The following example illustrates the symbol indirection process. We | |
389 use @code{fset} to set the function cell of a symbol and | |
390 @code{symbol-function} to get the function cell contents | |
391 (@pxref{Function Cells}). Specifically, we store the symbol @code{car} | |
392 into the function cell of @code{first}, and the symbol @code{first} into | |
393 the function cell of @code{erste}. | |
394 | |
395 @smallexample | |
396 @group | |
397 ;; @r{Build this function cell linkage:} | |
398 ;; ------------- ----- ------- ------- | |
399 ;; | #<subr car> | <-- | car | <-- | first | <-- | erste | | |
400 ;; ------------- ----- ------- ------- | |
401 @end group | |
402 @end smallexample | |
403 | |
404 @smallexample | |
405 @group | |
406 (symbol-function 'car) | |
407 @result{} #<subr car> | |
408 @end group | |
409 @group | |
410 (fset 'first 'car) | |
411 @result{} car | |
412 @end group | |
413 @group | |
414 (fset 'erste 'first) | |
415 @result{} first | |
416 @end group | |
417 @group | |
418 (erste '(1 2 3)) ; @r{Call the function referenced by @code{erste}.} | |
419 @result{} 1 | |
420 @end group | |
421 @end smallexample | |
422 | |
423 By contrast, the following example calls a function without any symbol | |
424 function indirection, because the first element is an anonymous Lisp | |
425 function, not a symbol. | |
426 | |
427 @smallexample | |
428 @group | |
429 ((lambda (arg) (erste arg)) | |
430 '(1 2 3)) | |
431 @result{} 1 | |
432 @end group | |
433 @end smallexample | |
434 | |
435 @noindent | |
436 After that function is called, its body is evaluated; this does | |
437 involve symbol function indirection when calling @code{erste}. | |
438 | |
439 The built-in function @code{indirect-function} provides an easy way to | |
440 perform symbol function indirection explicitly. | |
441 | |
442 @c Emacs 19 feature | |
443 @defun indirect-function function | |
444 This function returns the meaning of @var{function} as a function. If | |
445 @var{function} is a symbol, then it finds @var{function}'s function | |
446 definition and starts over with that value. If @var{function} is not a | |
447 symbol, then it returns @var{function} itself. | |
448 | |
449 Here is how you could define @code{indirect-function} in Lisp: | |
450 | |
451 @smallexample | |
452 (defun indirect-function (function) | |
453 (if (symbolp function) | |
454 (indirect-function (symbol-function function)) | |
455 function)) | |
456 @end smallexample | |
457 @end defun | |
458 | |
459 @node Function Forms | |
460 @subsection Evaluation of Function Forms | |
461 @cindex function form evaluation | |
462 @cindex function call | |
463 | |
464 If the first element of a list being evaluated is a Lisp function | |
465 object, byte-code object or primitive function object, then that list is | |
466 a @dfn{function call}. For example, here is a call to the function | |
467 @code{+}: | |
468 | |
469 @example | |
470 (+ 1 x) | |
471 @end example | |
472 | |
473 The first step ni evaluating a function call is to evaluate the | |
474 remaining elements of the list in the order they appear. The results | |
475 are the actual argument values, one value for each list element. The | |
476 next step is to call the function with this list of arguments, | |
477 effectively using the function @code{apply} (@pxref{Calling Functions}). | |
478 If the function is written in Lisp, the arguments are used to bind the | |
479 argument variables of the function (@pxref{Lambda Expressions}); then | |
480 the forms in the function body are evaluated in order, and the value of | |
481 the last body form becomes the value of the function call. | |
482 | |
483 @node Macro Forms | |
484 @subsection Lisp Macro Evaluation | |
485 @cindex macro call evaluation | |
486 | |
487 If the first element of a list being evaluated is a macro object, then | |
488 the list is a @dfn{macro call}. When a macro call is evaluated, the | |
489 elements of the rest of the list are @emph{not} initially evaluated. | |
490 Instead, these elements themselves are used as the arguments of the | |
491 macro. The macro definition computes a replacement form, called the | |
492 @dfn{expansion} of the macro, to be evaluated in place of the original | |
493 form. The expansion may be any sort of form: a self-evaluating | |
494 constant, a symbol or a list. If the expansion is itself a macro call, | |
495 this process of expansion repeats until some other sort of form results. | |
496 | |
497 Normally, the argument expressions are not evaluated as part of | |
498 computing the macro expansion, but instead appear as part of the | |
499 expansion, so they are evaluated when the expansion is evaluated. | |
500 | |
501 For example, given a macro defined as follows: | |
502 | |
503 @example | |
504 @group | |
505 (defmacro cadr (x) | |
506 (list 'car (list 'cdr x))) | |
507 @end group | |
508 @end example | |
509 | |
510 @noindent | |
511 an expression such as @code{(cadr (assq 'handler list))} is a macro | |
512 call, and its expansion is: | |
513 | |
514 @example | |
515 (car (cdr (assq 'handler list))) | |
516 @end example | |
517 | |
518 @noindent | |
519 Note that the argument @code{(assq 'handler list)} appears in the | |
520 expansion. | |
521 | |
522 @xref{Macros}, for a complete description of Emacs Lisp macros. | |
523 | |
524 @node Special Forms | |
525 @subsection Special Forms | |
526 @cindex special form evaluation | |
527 | |
528 A @dfn{special form} is a primitive function specially marked so that | |
529 its arguments are not all evaluated. Most special forms define control | |
530 structures or perform variable bindings---things which functions cannot | |
531 do. | |
532 | |
533 Each special form has its own rules for which arguments are evaluated | |
534 and which are used without evaluation. Whether a particular argument is | |
535 evaluated may depend on the results of evaluating other arguments. | |
536 | |
537 Here is a list, in alphabetical order, of all of the special forms in | |
538 Emacs Lisp with a reference to where each is described. | |
539 | |
540 @table @code | |
541 @item and | |
542 @pxref{Combining Conditions} | |
543 | |
544 @item catch | |
545 @pxref{Catch and Throw} | |
546 | |
547 @item cond | |
548 @pxref{Conditionals} | |
549 | |
550 @item condition-case | |
551 @pxref{Handling Errors} | |
552 | |
553 @item defconst | |
554 @pxref{Defining Variables} | |
555 | |
556 @item defmacro | |
557 @pxref{Defining Macros} | |
558 | |
559 @item defun | |
560 @pxref{Defining Functions} | |
561 | |
562 @item defvar | |
563 @pxref{Defining Variables} | |
564 | |
565 @item function | |
566 @pxref{Anonymous Functions} | |
567 | |
568 @item if | |
569 @pxref{Conditionals} | |
570 | |
571 @item interactive | |
572 @pxref{Interactive Call} | |
573 | |
574 @item let | |
575 @itemx let* | |
576 @pxref{Local Variables} | |
577 | |
578 @item or | |
579 @pxref{Combining Conditions} | |
580 | |
581 @item prog1 | |
582 @itemx prog2 | |
583 @itemx progn | |
584 @pxref{Sequencing} | |
585 | |
586 @item quote | |
587 @pxref{Quoting} | |
588 | |
589 @item save-excursion | |
590 @pxref{Excursions} | |
591 | |
592 @item save-restriction | |
593 @pxref{Narrowing} | |
594 | |
595 @item save-window-excursion | |
596 @pxref{Window Configurations} | |
597 | |
598 @item setq | |
599 @pxref{Setting Variables} | |
600 | |
601 @item setq-default | |
602 @pxref{Creating Buffer-Local} | |
603 | |
604 @item track-mouse | |
605 @pxref{Mouse Tracking} | |
606 | |
607 @item unwind-protect | |
608 @pxref{Nonlocal Exits} | |
609 | |
610 @item while | |
611 @pxref{Iteration} | |
612 | |
613 @item with-output-to-temp-buffer | |
614 @pxref{Temporary Displays} | |
615 @end table | |
616 | |
617 @cindex CL note---special forms compared | |
618 @quotation | |
619 @b{Common Lisp note:} here are some comparisons of special forms in | |
620 GNU Emacs Lisp and Common Lisp. @code{setq}, @code{if}, and | |
621 @code{catch} are special forms in both Emacs Lisp and Common Lisp. | |
622 @code{defun} is a special form in Emacs Lisp, but a macro in Common | |
623 Lisp. @code{save-excursion} is a special form in Emacs Lisp, but | |
624 doesn't exist in Common Lisp. @code{throw} is a special form in | |
625 Common Lisp (because it must be able to throw multiple values), but it | |
626 is a function in Emacs Lisp (which doesn't have multiple | |
627 values).@refill | |
628 @end quotation | |
629 | |
630 @node Autoloading | |
631 @subsection Autoloading | |
632 | |
633 The @dfn{autoload} feature allows you to call a function or macro | |
634 whose function definition has not yet been loaded into Emacs. It | |
635 specifies which file contains the definition. When an autoload object | |
636 appears as a symbol's function definition, calling that symbol as a | |
637 function automatically loads the specified file; then it calls the real | |
638 definition loaded from that file. @xref{Autoload}. | |
639 | |
640 @node Quoting | |
641 @section Quoting | |
642 @cindex quoting | |
643 | |
644 The special form @code{quote} returns its single argument | |
645 ``unchanged''. | |
646 | |
647 @defspec quote object | |
648 This special form returns @var{object}, without evaluating it. This | |
649 provides a way to include constant symbols and lists, which are not | |
650 self-evaluating objects, in a program. (It is not necessary to quote | |
651 self-evaluating objects such as numbers, strings, and vectors.) | |
652 | |
653 @cindex @samp{'} for quoting | |
654 @cindex quoting using apostrophe | |
655 @cindex apostrophe for quoting | |
656 Because @code{quote} is used so often in programs, Lisp provides a | |
657 convenient read syntax for it. An apostrophe character (@samp{'}) | |
658 followed by a Lisp object (in read syntax) expands to a list whose first | |
659 element is @code{quote}, and whose second element is the object. Thus, | |
660 the read syntax @code{'x} is an abbreviation for @code{(quote x)}. | |
661 | |
662 Here are some examples of expressions that use @code{quote}: | |
663 | |
664 @example | |
665 @group | |
666 (quote (+ 1 2)) | |
667 @result{} (+ 1 2) | |
668 @end group | |
669 @group | |
670 (quote foo) | |
671 @result{} foo | |
672 @end group | |
673 @group | |
674 'foo | |
675 @result{} foo | |
676 @end group | |
677 @group | |
678 ''foo | |
679 @result{} (quote foo) | |
680 @end group | |
681 @group | |
682 '(quote foo) | |
683 @result{} (quote foo) | |
684 @end group | |
685 @group | |
686 ['foo] | |
687 @result{} [(quote foo)] | |
688 @end group | |
689 @end example | |
690 @end defspec | |
691 | |
692 Other quoting constructs include @code{function} (@pxref{Anonymous | |
693 Functions}), which causes an anonymous lambda expression written in Lisp | |
694 to be compiled, and @code{`} (@pxref{Backquote}), which is used to quote | |
695 only part of a list, while computing and substituting other parts. |