Mercurial > hg > xemacs-beta
annotate man/lispref/eval.texi @ 5044:e84a30b0e4a2
remove duplicative code in change_frame_size()
-------------------- ChangeLog entries follow: --------------------
src/ChangeLog addition:
2010-02-15 Ben Wing <ben@xemacs.org>
* frame.c (change_frame_size_1):
Simplify the logic in this function.
(1) Don't allow 0 as the value of height or width. The old code
that tried to allow this was totally broken, anyway, so obviously
this never happens any more.
(2) Don't duplicate the code in frame_conversion_internal() that
converts displayable pixel size to total pixel size -- just call
that function.
| author | Ben Wing <ben@xemacs.org> |
|---|---|
| date | Mon, 15 Feb 2010 22:58:10 -0600 |
| parents | 755ae5b97edb |
| children | 378a34562cbe |
| rev | line source |
|---|---|
| 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. | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
255 * Special Operators:: ``Special operators'' are idiosyncratic primitives, |
| 428 | 256 most of them extremely important. |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
257 Also known as special forms. |
| 428 | 258 * Autoloading:: Functions set up to load files |
| 259 containing their real definitions. | |
| 260 @end menu | |
| 261 | |
| 262 @node Self-Evaluating Forms | |
| 263 @subsection Self-Evaluating Forms | |
| 264 @cindex vector evaluation | |
| 265 @cindex literal evaluation | |
| 266 @cindex self-evaluating form | |
| 267 | |
| 268 A @dfn{self-evaluating form} is any form that is not a list or symbol. | |
| 269 Self-evaluating forms evaluate to themselves: the result of evaluation | |
| 270 is the same object that was evaluated. Thus, the number 25 evaluates to | |
| 271 25, and the string @code{"foo"} evaluates to the string @code{"foo"}. | |
| 272 Likewise, evaluation of a vector does not cause evaluation of the | |
| 273 elements of the vector---it returns the same vector with its contents | |
| 274 unchanged. | |
| 275 | |
| 276 @example | |
| 277 @group | |
| 278 '123 ; @r{An object, shown without evaluation.} | |
| 279 @result{} 123 | |
| 280 @end group | |
| 281 @group | |
| 282 123 ; @r{Evaluated as usual---result is the same.} | |
| 283 @result{} 123 | |
| 284 @end group | |
| 285 @group | |
| 286 (eval '123) ; @r{Evaluated ``by hand''---result is the same.} | |
| 287 @result{} 123 | |
| 288 @end group | |
| 289 @group | |
| 290 (eval (eval '123)) ; @r{Evaluating twice changes nothing.} | |
| 291 @result{} 123 | |
| 292 @end group | |
| 293 @end example | |
| 294 | |
| 295 It is common to write numbers, characters, strings, and even vectors | |
| 296 in Lisp code, taking advantage of the fact that they self-evaluate. | |
| 297 However, it is quite unusual to do this for types that lack a read | |
| 298 syntax, because there's no way to write them textually. It is possible | |
| 299 to construct Lisp expressions containing these types by means of a Lisp | |
| 300 program. Here is an example: | |
| 301 | |
| 302 @example | |
| 303 @group | |
| 304 ;; @r{Build an expression containing a buffer object.} | |
| 305 (setq buffer (list 'print (current-buffer))) | |
| 306 @result{} (print #<buffer eval.texi>) | |
| 307 @end group | |
| 308 @group | |
| 309 ;; @r{Evaluate it.} | |
| 310 (eval buffer) | |
| 311 @print{} #<buffer eval.texi> | |
| 312 @result{} #<buffer eval.texi> | |
| 313 @end group | |
| 314 @end example | |
| 315 | |
| 316 @node Symbol Forms | |
| 317 @subsection Symbol Forms | |
| 318 @cindex symbol evaluation | |
| 319 | |
| 320 When a symbol is evaluated, it is treated as a variable. The result | |
| 321 is the variable's value, if it has one. If it has none (if its value | |
| 322 cell is void), an error is signaled. For more information on the use of | |
| 323 variables, see @ref{Variables}. | |
| 324 | |
| 325 In the following example, we set the value of a symbol with | |
| 326 @code{setq}. Then we evaluate the symbol, and get back the value that | |
| 327 @code{setq} stored. | |
| 328 | |
| 329 @example | |
| 330 @group | |
| 331 (setq a 123) | |
| 332 @result{} 123 | |
| 333 @end group | |
| 334 @group | |
| 335 (eval 'a) | |
| 336 @result{} 123 | |
| 337 @end group | |
| 338 @group | |
| 339 a | |
| 340 @result{} 123 | |
| 341 @end group | |
| 342 @end example | |
| 343 | |
| 344 The symbols @code{nil} and @code{t} are treated specially, so that the | |
| 345 value of @code{nil} is always @code{nil}, and the value of @code{t} is | |
| 346 always @code{t}; you cannot set or bind them to any other values. Thus, | |
| 347 these two symbols act like self-evaluating forms, even though | |
| 348 @code{eval} treats them like any other symbol. | |
| 349 | |
| 350 @node Classifying Lists | |
| 351 @subsection Classification of List Forms | |
| 352 @cindex list form evaluation | |
| 353 | |
| 354 A form that is a nonempty list is either a function call, a macro | |
| 355 call, or a special form, according to its first element. These three | |
| 356 kinds of forms are evaluated in different ways, described below. The | |
| 357 remaining list elements constitute the @dfn{arguments} for the function, | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
358 macro, or special operator. |
| 428 | 359 |
| 360 The first step in evaluating a nonempty list is to examine its first | |
| 361 element. This element alone determines what kind of form the list is | |
| 362 and how the rest of the list is to be processed. The first element is | |
| 363 @emph{not} evaluated, as it would be in some Lisp dialects such as | |
| 364 Scheme. | |
| 365 | |
| 366 @node Function Indirection | |
| 367 @subsection Symbol Function Indirection | |
| 368 @cindex symbol function indirection | |
| 369 @cindex indirection | |
| 370 @cindex void function | |
| 371 | |
| 372 If the first element of the list is a symbol then evaluation examines | |
| 373 the symbol's function cell, and uses its contents instead of the | |
| 374 original symbol. If the contents are another symbol, this process, | |
| 375 called @dfn{symbol function indirection}, is repeated until it obtains a | |
| 376 non-symbol. @xref{Function Names}, for more information about using a | |
| 377 symbol as a name for a function stored in the function cell of the | |
| 378 symbol. | |
| 379 | |
| 380 One possible consequence of this process is an infinite loop, in the | |
| 381 event that a symbol's function cell refers to the same symbol. Or a | |
| 382 symbol may have a void function cell, in which case the subroutine | |
| 383 @code{symbol-function} signals a @code{void-function} error. But if | |
| 384 neither of these things happens, we eventually obtain a non-symbol, | |
| 385 which ought to be a function or other suitable object. | |
| 386 | |
| 387 @kindex invalid-function | |
| 388 @cindex invalid function | |
| 389 More precisely, we should now have a Lisp function (a lambda | |
| 390 expression), a byte-code function, a primitive function, a Lisp macro, a | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
391 special operator, or an autoload object. Each of these types is a case |
| 428 | 392 described in one of the following sections. If the object is not one of |
| 393 these types, the error @code{invalid-function} is signaled. | |
| 394 | |
| 395 The following example illustrates the symbol indirection process. We | |
| 396 use @code{fset} to set the function cell of a symbol and | |
| 397 @code{symbol-function} to get the function cell contents | |
| 398 (@pxref{Function Cells}). Specifically, we store the symbol @code{car} | |
| 399 into the function cell of @code{first}, and the symbol @code{first} into | |
| 400 the function cell of @code{erste}. | |
| 401 | |
| 402 @smallexample | |
| 403 @group | |
| 404 ;; @r{Build this function cell linkage:} | |
| 405 ;; ------------- ----- ------- ------- | |
| 406 ;; | #<subr car> | <-- | car | <-- | first | <-- | erste | | |
| 407 ;; ------------- ----- ------- ------- | |
| 408 @end group | |
| 409 @end smallexample | |
| 410 | |
| 411 @smallexample | |
| 412 @group | |
| 413 (symbol-function 'car) | |
| 414 @result{} #<subr car> | |
| 415 @end group | |
| 416 @group | |
| 417 (fset 'first 'car) | |
| 418 @result{} car | |
| 419 @end group | |
| 420 @group | |
| 421 (fset 'erste 'first) | |
| 422 @result{} first | |
| 423 @end group | |
| 424 @group | |
| 425 (erste '(1 2 3)) ; @r{Call the function referenced by @code{erste}.} | |
| 426 @result{} 1 | |
| 427 @end group | |
| 428 @end smallexample | |
| 429 | |
| 430 By contrast, the following example calls a function without any symbol | |
| 431 function indirection, because the first element is an anonymous Lisp | |
| 432 function, not a symbol. | |
| 433 | |
| 434 @smallexample | |
| 435 @group | |
| 436 ((lambda (arg) (erste arg)) | |
| 444 | 437 '(1 2 3)) |
| 428 | 438 @result{} 1 |
| 439 @end group | |
| 440 @end smallexample | |
| 441 | |
| 442 @noindent | |
| 443 Executing the function itself evaluates its body; this does involve | |
| 444 symbol function indirection when calling @code{erste}. | |
| 445 | |
| 446 The built-in function @code{indirect-function} provides an easy way to | |
| 447 perform symbol function indirection explicitly. | |
| 448 | |
| 444 | 449 @defun indirect-function object |
| 450 This function returns the meaning of @var{object} as a function. If | |
| 451 @var{object} is a symbol, then it finds @var{object}'s function | |
| 452 definition and starts over with that value. If @var{object} is not a | |
| 453 symbol, then it returns @var{object} itself. | |
| 428 | 454 |
| 455 Here is how you could define @code{indirect-function} in Lisp: | |
| 456 | |
| 457 @smallexample | |
| 458 (defun indirect-function (function) | |
| 459 (if (symbolp function) | |
| 460 (indirect-function (symbol-function function)) | |
| 461 function)) | |
| 462 @end smallexample | |
| 463 @end defun | |
| 464 | |
| 465 @node Function Forms | |
| 466 @subsection Evaluation of Function Forms | |
| 467 @cindex function form evaluation | |
| 468 @cindex function call | |
| 469 | |
| 470 If the first element of a list being evaluated is a Lisp function | |
| 471 object, byte-code object or primitive function object, then that list is | |
| 472 a @dfn{function call}. For example, here is a call to the function | |
| 473 @code{+}: | |
| 474 | |
| 475 @example | |
| 476 (+ 1 x) | |
| 477 @end example | |
| 478 | |
| 479 The first step in evaluating a function call is to evaluate the | |
| 480 remaining elements of the list from left to right. The results are the | |
| 481 actual argument values, one value for each list element. The next step | |
| 482 is to call the function with this list of arguments, effectively using | |
| 483 the function @code{apply} (@pxref{Calling Functions}). If the function | |
| 484 is written in Lisp, the arguments are used to bind the argument | |
| 485 variables of the function (@pxref{Lambda Expressions}); then the forms | |
| 486 in the function body are evaluated in order, and the value of the last | |
| 487 body form becomes the value of the function call. | |
| 488 | |
| 489 @node Macro Forms | |
| 490 @subsection Lisp Macro Evaluation | |
| 491 @cindex macro call evaluation | |
| 492 | |
| 493 If the first element of a list being evaluated is a macro object, then | |
| 494 the list is a @dfn{macro call}. When a macro call is evaluated, the | |
| 495 elements of the rest of the list are @emph{not} initially evaluated. | |
| 496 Instead, these elements themselves are used as the arguments of the | |
| 497 macro. The macro definition computes a replacement form, called the | |
| 498 @dfn{expansion} of the macro, to be evaluated in place of the original | |
| 499 form. The expansion may be any sort of form: a self-evaluating | |
| 500 constant, a symbol, or a list. If the expansion is itself a macro call, | |
| 501 this process of expansion repeats until some other sort of form results. | |
| 502 | |
| 503 Ordinary evaluation of a macro call finishes by evaluating the | |
| 504 expansion. However, the macro expansion is not necessarily evaluated | |
| 505 right away, or at all, because other programs also expand macro calls, | |
| 506 and they may or may not evaluate the expansions. | |
| 507 | |
| 508 Normally, the argument expressions are not evaluated as part of | |
| 509 computing the macro expansion, but instead appear as part of the | |
| 510 expansion, so they are computed when the expansion is computed. | |
| 511 | |
| 512 For example, given a macro defined as follows: | |
| 513 | |
| 514 @example | |
| 515 @group | |
| 516 (defmacro cadr (x) | |
| 517 (list 'car (list 'cdr x))) | |
| 518 @end group | |
| 519 @end example | |
| 520 | |
| 521 @noindent | |
| 522 an expression such as @code{(cadr (assq 'handler list))} is a macro | |
| 523 call, and its expansion is: | |
| 524 | |
| 525 @example | |
| 526 (car (cdr (assq 'handler list))) | |
| 527 @end example | |
| 528 | |
| 529 @noindent | |
| 530 Note that the argument @code{(assq 'handler list)} appears in the | |
| 531 expansion. | |
| 532 | |
| 533 @xref{Macros}, for a complete description of XEmacs Lisp macros. | |
| 534 | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
535 @node Special Operators |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
536 @subsection Special Operators |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
537 @cindex special operator evaluation |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
538 @cindex special form |
| 428 | 539 |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
540 A @dfn{special operator} (historically, and less logically, a |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
541 @dfn{special form}) is a primitive function specially marked so that |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
542 its arguments are not all evaluated. Most special operators define control |
| 428 | 543 structures or perform variable bindings---things which functions cannot |
| 544 do. | |
| 545 | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
546 Each special operator has its own rules for which arguments are evaluated |
| 428 | 547 and which are used without evaluation. Whether a particular argument is |
| 548 evaluated may depend on the results of evaluating other arguments. | |
| 549 | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
550 Here is a list, in alphabetical order, of all of the special operators in |
| 428 | 551 XEmacs Lisp with a reference to where each is described. |
| 552 | |
| 553 @table @code | |
| 554 @item and | |
| 555 @pxref{Combining Conditions} | |
| 556 | |
| 557 @item catch | |
| 558 @pxref{Catch and Throw} | |
| 559 | |
| 560 @item cond | |
| 561 @pxref{Conditionals} | |
| 562 | |
| 563 @item condition-case | |
| 564 @pxref{Handling Errors} | |
| 565 | |
| 566 @item defconst | |
| 567 @pxref{Defining Variables} | |
| 568 | |
| 569 @item defmacro | |
| 570 @pxref{Defining Macros} | |
| 571 | |
| 572 @item defun | |
| 573 @pxref{Defining Functions} | |
| 574 | |
| 575 @item defvar | |
| 576 @pxref{Defining Variables} | |
| 577 | |
| 578 @item function | |
| 579 @pxref{Anonymous Functions} | |
| 580 | |
| 581 @item if | |
| 582 @pxref{Conditionals} | |
| 583 | |
| 584 @item interactive | |
| 585 @pxref{Interactive Call} | |
| 586 | |
| 587 @item let | |
| 588 @itemx let* | |
| 589 @pxref{Local Variables} | |
| 590 | |
| 591 @item or | |
| 592 @pxref{Combining Conditions} | |
| 593 | |
| 594 @item prog1 | |
| 595 @itemx prog2 | |
| 596 @itemx progn | |
| 597 @pxref{Sequencing} | |
| 598 | |
| 599 @item quote | |
| 600 @pxref{Quoting} | |
| 601 | |
| 602 @item save-current-buffer | |
| 603 @pxref{Excursions} | |
| 604 | |
| 605 @item save-excursion | |
| 606 @pxref{Excursions} | |
| 607 | |
| 608 @item save-restriction | |
| 609 @pxref{Narrowing} | |
| 610 | |
| 611 @item save-selected-window | |
| 612 @pxref{Excursions} | |
| 613 | |
| 614 @item save-window-excursion | |
| 615 @pxref{Window Configurations} | |
| 616 | |
| 617 @item setq | |
| 618 @pxref{Setting Variables} | |
| 619 | |
| 620 @item setq-default | |
| 621 @pxref{Creating Buffer-Local} | |
| 622 | |
| 623 @item unwind-protect | |
| 624 @pxref{Nonlocal Exits} | |
| 625 | |
| 626 @item while | |
| 627 @pxref{Iteration} | |
| 628 | |
| 629 @item with-output-to-temp-buffer | |
| 630 @pxref{Temporary Displays} | |
| 631 @end table | |
| 632 | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
633 @cindex CL note---special operators compared |
| 428 | 634 @quotation |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
635 @b{Common Lisp note:} here are some comparisons of special operators in |
| 428 | 636 XEmacs Lisp and Common Lisp. @code{setq}, @code{if}, and |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
637 @code{catch} are special operators in both XEmacs Lisp and Common Lisp. |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
638 @code{defun} is a special operator in XEmacs Lisp, but a macro in Common |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
639 Lisp. @code{save-excursion} is a special operator in XEmacs Lisp, but |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
640 doesn't exist in Common Lisp. @code{throw} is a special operator in |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
641 both Common Lisp and XEmacs Lisp (because it must be able to throw |
|
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
642 multiple values).@refill |
| 428 | 643 @end quotation |
| 644 | |
| 645 @node Autoloading | |
| 646 @subsection Autoloading | |
| 647 | |
| 648 The @dfn{autoload} feature allows you to call a function or macro | |
| 649 whose function definition has not yet been loaded into XEmacs. It | |
| 650 specifies which file contains the definition. When an autoload object | |
| 651 appears as a symbol's function definition, calling that symbol as a | |
| 652 function automatically loads the specified file; then it calls the real | |
| 653 definition loaded from that file. @xref{Autoload}. | |
| 654 | |
| 655 @node Quoting | |
| 656 @section Quoting | |
| 657 @cindex quoting | |
| 658 | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
659 The special operator @code{quote} returns its single argument, as written, |
| 428 | 660 without evaluating it. This provides a way to include constant symbols |
| 661 and lists, which are not self-evaluating objects, in a program. (It is | |
| 662 not necessary to quote self-evaluating objects such as numbers, strings, | |
| 663 and vectors.) | |
| 664 | |
| 665 @defspec quote object | |
|
4905
755ae5b97edb
Change "special form" to "special operator" in our sources.
Aidan Kehoe <kehoea@parhasard.net>
parents:
2492
diff
changeset
|
666 This special operator returns @var{object}, without evaluating it. |
| 428 | 667 @end defspec |
| 668 | |
| 669 @cindex @samp{'} for quoting | |
| 670 @cindex quoting using apostrophe | |
| 671 @cindex apostrophe for quoting | |
| 672 Because @code{quote} is used so often in programs, Lisp provides a | |
| 673 convenient read syntax for it. An apostrophe character (@samp{'}) | |
| 674 followed by a Lisp object (in read syntax) expands to a list whose first | |
| 675 element is @code{quote}, and whose second element is the object. Thus, | |
| 676 the read syntax @code{'x} is an abbreviation for @code{(quote x)}. | |
| 677 | |
| 678 Here are some examples of expressions that use @code{quote}: | |
| 679 | |
| 680 @example | |
| 681 @group | |
| 682 (quote (+ 1 2)) | |
| 683 @result{} (+ 1 2) | |
| 684 @end group | |
| 685 @group | |
| 686 (quote foo) | |
| 687 @result{} foo | |
| 688 @end group | |
| 689 @group | |
| 690 'foo | |
| 691 @result{} foo | |
| 692 @end group | |
| 693 @group | |
| 694 ''foo | |
| 695 @result{} (quote foo) | |
| 696 @end group | |
| 697 @group | |
| 698 '(quote foo) | |
| 699 @result{} (quote foo) | |
| 700 @end group | |
| 701 @group | |
| 702 ['foo] | |
| 703 @result{} [(quote foo)] | |
| 704 @end group | |
| 705 @end example | |
| 706 | |
| 707 Other quoting constructs include @code{function} (@pxref{Anonymous | |
| 708 Functions}), which causes an anonymous lambda expression written in Lisp | |
| 709 to be compiled, and @samp{`} (@pxref{Backquote}), which is used to quote | |
| 710 only part of a list, while computing and substituting other parts. |