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