Mercurial > hg > xemacs-beta
annotate man/lispref/eval.texi @ 4905:755ae5b97edb
Change "special form" to "special operator" in our sources.
Add a compatible function alias, and the relevant manual index entries.
src/ChangeLog addition:
2010-01-31 Aidan Kehoe <kehoea@parhasard.net>
* symbols.c (Fspecial_operator_p, syms_of_symbols):
* eval.c (print_subr, Finteractive_p, Ffuncall)
(Ffunction_min_args, Ffunction_max_args, vars_of_eval):
* editfns.c:
* data.c (Fsubr_max_args):
* doc.c (Fbuilt_in_symbol_file):
Change "special form" to "special operator" in our sources.
man/ChangeLog addition:
2010-01-31 Aidan Kehoe <kehoea@parhasard.net>
* xemacs/programs.texi (Defuns):
* lispref/variables.texi (Local Variables, Defining Variables)
(Setting Variables, Default Value):
* lispref/symbols.texi (Definitions):
* lispref/searching.texi (Saving Match Data):
* lispref/positions.texi (Excursions, Narrowing):
* lispref/objects.texi (Primitive Function Type):
* lispref/macros.texi (Defining Macros, Backquote):
* lispref/lispref.texi (Top):
* lispref/intro.texi (A Sample Function Description):
* lispref/help.texi (Help Functions):
* lispref/functions.texi (What Is a Function, Simple Lambda)
(Defining Functions, Calling Functions, Anonymous Functions):
* lispref/frames.texi (Input Focus):
* lispref/eval.texi (Forms, Function Indirection)
(Special Operators, Quoting):
* lispref/edebug-inc.texi (Instrumenting)
(Specification Examples):
* lispref/debugging.texi (Internals of Debugger):
* lispref/control.texi (Control Structures, Sequencing):
(Conditionals, Combining Conditions, Iteration):
(Catch and Throw, Handling Errors):
* lispref/commands.texi (Defining Commands, Using Interactive):
Terminology change; special operator -> special form.
Don't attempt to change this in texinfo.texi or cl.texi, which use
macros I don't understand.
* lispref/macros.texi (Defining Macros): Give an anonymous macro
example here.
* lispref/positions.texi (Excursions):
Correct some documentation that called a couple of macros special
forms.
* lispref/searching.texi (Saving Match Data):
Drop some documentation of how to write code that works with Emacs
18.
* lispref/specifiers.texi (Adding Specifications):
Correct this; #'let-specifier is a macro, not a special operator.
* lispref/windows.texi (Window Configurations)
(Selecting Windows):
Correct this, #'save-selected-window and #'save-window-excursion
are macros, not special operators.
lisp/ChangeLog addition:
2010-01-31 Aidan Kehoe <kehoea@parhasard.net>
* obsolete.el:
* loadhist.el (symbol-file):
* help.el (describe-function-1):
* bytecomp.el: (byte-compile-save-current-buffer):
* byte-optimize.el (byte-optimize-form-code-walker):
* subr.el (subr-arity):
Change "special form" to "special operator" in these files, it's
the more logical term.
* subr.el (special-form-p): Provide this alias for
#'special-operator-p.
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Sun, 31 Jan 2010 20:28:01 +0000 |
| parents | 6780963faf78 |
| 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. |