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/functions.info
+ − 6 @node Functions, Macros, Variables, Top
+ − 7 @chapter Functions
+ − 8
+ − 9 A Lisp program is composed mainly of Lisp functions. This chapter
+ − 10 explains what functions are, how they accept arguments, and how to
+ − 11 define them.
+ − 12
+ − 13 @menu
+ − 14 * What Is a Function:: Lisp functions vs. primitives; terminology.
+ − 15 * Lambda Expressions:: How functions are expressed as Lisp objects.
+ − 16 * Function Names:: A symbol can serve as the name of a function.
+ − 17 * Defining Functions:: Lisp expressions for defining functions.
+ − 18 * Calling Functions:: How to use an existing function.
+ − 19 * Mapping Functions:: Applying a function to each element of a list, etc.
444
+ − 20 * Anonymous Functions:: Lambda expressions are functions with no names.
428
+ − 21 * Function Cells:: Accessing or setting the function definition
+ − 22 of a symbol.
+ − 23 * Inline Functions:: Defining functions that the compiler will open code.
+ − 24 * Related Topics:: Cross-references to specific Lisp primitives
+ − 25 that have a special bearing on how functions work.
+ − 26 @end menu
+ − 27
+ − 28 @node What Is a Function
+ − 29 @section What Is a Function?
+ − 30
+ − 31 In a general sense, a function is a rule for carrying on a computation
+ − 32 given several values called @dfn{arguments}. The result of the
+ − 33 computation is called the value of the function. The computation can
+ − 34 also have side effects: lasting changes in the values of variables or
+ − 35 the contents of data structures.
+ − 36
+ − 37 Here are important terms for functions in XEmacs Lisp and for other
+ − 38 function-like objects.
+ − 39
+ − 40 @table @dfn
+ − 41 @item function
+ − 42 @cindex function
+ − 43 In XEmacs Lisp, a @dfn{function} is anything that can be applied to
+ − 44 arguments in a Lisp program. In some cases, we use it more
+ − 45 specifically to mean a function written in Lisp. Special forms and
+ − 46 macros are not functions.
+ − 47
+ − 48 @item primitive
+ − 49 @cindex primitive
+ − 50 @cindex subr
+ − 51 @cindex built-in function
+ − 52 A @dfn{primitive} is a function callable from Lisp that is written in C,
+ − 53 such as @code{car} or @code{append}. These functions are also called
+ − 54 @dfn{built-in} functions or @dfn{subrs}. (Special forms are also
+ − 55 considered primitives.)
+ − 56
+ − 57 Usually the reason that a function is a primitives is because it is
+ − 58 fundamental, because it provides a low-level interface to operating
+ − 59 system services, or because it needs to run fast. Primitives can be
+ − 60 modified or added only by changing the C sources and recompiling the
+ − 61 editor. See @ref{Writing Lisp Primitives,,, internals, XEmacs
+ − 62 Internals Manual}.
+ − 63
+ − 64 @item lambda expression
+ − 65 A @dfn{lambda expression} is a function written in Lisp.
+ − 66 These are described in the following section.
+ − 67 @ifinfo
+ − 68 @xref{Lambda Expressions}.
+ − 69 @end ifinfo
+ − 70
+ − 71 @item special form
+ − 72 A @dfn{special form} is a primitive that is like a function but does not
+ − 73 evaluate all of its arguments in the usual way. It may evaluate only
+ − 74 some of the arguments, or may evaluate them in an unusual order, or
+ − 75 several times. Many special forms are described in @ref{Control
+ − 76 Structures}.
+ − 77
+ − 78 @item macro
+ − 79 @cindex macro
+ − 80 A @dfn{macro} is a construct defined in Lisp by the programmer. It
+ − 81 differs from a function in that it translates a Lisp expression that you
+ − 82 write into an equivalent expression to be evaluated instead of the
+ − 83 original expression. Macros enable Lisp programmers to do the sorts of
+ − 84 things that special forms can do. @xref{Macros}, for how to define and
+ − 85 use macros.
+ − 86
+ − 87 @item command
+ − 88 @cindex command
+ − 89 A @dfn{command} is an object that @code{command-execute} can invoke; it
+ − 90 is a possible definition for a key sequence. Some functions are
+ − 91 commands; a function written in Lisp is a command if it contains an
+ − 92 interactive declaration (@pxref{Defining Commands}). Such a function
+ − 93 can be called from Lisp expressions like other functions; in this case,
+ − 94 the fact that the function is a command makes no difference.
+ − 95
+ − 96 Keyboard macros (strings and vectors) are commands also, even though
+ − 97 they are not functions. A symbol is a command if its function
+ − 98 definition is a command; such symbols can be invoked with @kbd{M-x}.
+ − 99 The symbol is a function as well if the definition is a function.
+ − 100 @xref{Command Overview}.
+ − 101
+ − 102 @item keystroke command
+ − 103 @cindex keystroke command
+ − 104 A @dfn{keystroke command} is a command that is bound to a key sequence
+ − 105 (typically one to three keystrokes). The distinction is made here
+ − 106 merely to avoid confusion with the meaning of ``command'' in non-Emacs
+ − 107 editors; for Lisp programs, the distinction is normally unimportant.
+ − 108
+ − 109 @item compiled function
+ − 110 A @dfn{compiled function} is a function that has been compiled by the
+ − 111 byte compiler. @xref{Compiled-Function Type}.
+ − 112 @end table
+ − 113
+ − 114 @defun subrp object
+ − 115 This function returns @code{t} if @var{object} is a built-in function
+ − 116 (i.e., a Lisp primitive).
+ − 117
+ − 118 @example
+ − 119 @group
+ − 120 (subrp 'message) ; @r{@code{message} is a symbol,}
+ − 121 @result{} nil ; @r{not a subr object.}
+ − 122 @end group
+ − 123 @group
+ − 124 (subrp (symbol-function 'message))
+ − 125 @result{} t
+ − 126 @end group
+ − 127 @end example
+ − 128 @end defun
+ − 129
+ − 130 @defun compiled-function-p object
+ − 131 This function returns @code{t} if @var{object} is a compiled
+ − 132 function. For example:
+ − 133
+ − 134 @example
+ − 135 @group
+ − 136 (compiled-function-p (symbol-function 'next-line))
+ − 137 @result{} t
+ − 138 @end group
+ − 139 @end example
+ − 140 @end defun
+ − 141
+ − 142 @node Lambda Expressions
+ − 143 @section Lambda Expressions
+ − 144 @cindex lambda expression
+ − 145
+ − 146 A function written in Lisp is a list that looks like this:
+ − 147
+ − 148 @example
+ − 149 (lambda (@var{arg-variables}@dots{})
+ − 150 @r{[}@var{documentation-string}@r{]}
+ − 151 @r{[}@var{interactive-declaration}@r{]}
+ − 152 @var{body-forms}@dots{})
+ − 153 @end example
+ − 154
+ − 155 @noindent
+ − 156 Such a list is called a @dfn{lambda expression}. In XEmacs Lisp, it
+ − 157 actually is valid as an expression---it evaluates to itself. In some
+ − 158 other Lisp dialects, a lambda expression is not a valid expression at
+ − 159 all. In either case, its main use is not to be evaluated as an
+ − 160 expression, but to be called as a function.
+ − 161
+ − 162 @menu
+ − 163 * Lambda Components:: The parts of a lambda expression.
+ − 164 * Simple Lambda:: A simple example.
+ − 165 * Argument List:: Details and special features of argument lists.
+ − 166 * Function Documentation:: How to put documentation in a function.
+ − 167 @end menu
+ − 168
+ − 169 @node Lambda Components
+ − 170 @subsection Components of a Lambda Expression
+ − 171
+ − 172 @ifinfo
+ − 173
+ − 174 A function written in Lisp (a ``lambda expression'') is a list that
+ − 175 looks like this:
+ − 176
+ − 177 @example
+ − 178 (lambda (@var{arg-variables}@dots{})
+ − 179 [@var{documentation-string}]
+ − 180 [@var{interactive-declaration}]
+ − 181 @var{body-forms}@dots{})
+ − 182 @end example
+ − 183 @end ifinfo
+ − 184
+ − 185 @cindex lambda list
+ − 186 The first element of a lambda expression is always the symbol
+ − 187 @code{lambda}. This indicates that the list represents a function. The
+ − 188 reason functions are defined to start with @code{lambda} is so that
+ − 189 other lists, intended for other uses, will not accidentally be valid as
+ − 190 functions.
+ − 191
+ − 192 The second element is a list of symbols--the argument variable names.
+ − 193 This is called the @dfn{lambda list}. When a Lisp function is called,
+ − 194 the argument values are matched up against the variables in the lambda
+ − 195 list, which are given local bindings with the values provided.
+ − 196 @xref{Local Variables}.
+ − 197
+ − 198 The documentation string is a Lisp string object placed within the
+ − 199 function definition to describe the function for the XEmacs help
+ − 200 facilities. @xref{Function Documentation}.
+ − 201
+ − 202 The interactive declaration is a list of the form @code{(interactive
+ − 203 @var{code-string})}. This declares how to provide arguments if the
+ − 204 function is used interactively. Functions with this declaration are called
+ − 205 @dfn{commands}; they can be called using @kbd{M-x} or bound to a key.
+ − 206 Functions not intended to be called in this way should not have interactive
+ − 207 declarations. @xref{Defining Commands}, for how to write an interactive
+ − 208 declaration.
+ − 209
+ − 210 @cindex body of function
+ − 211 The rest of the elements are the @dfn{body} of the function: the Lisp
+ − 212 code to do the work of the function (or, as a Lisp programmer would say,
+ − 213 ``a list of Lisp forms to evaluate''). The value returned by the
+ − 214 function is the value returned by the last element of the body.
+ − 215
+ − 216 @node Simple Lambda
+ − 217 @subsection A Simple Lambda-Expression Example
+ − 218
+ − 219 Consider for example the following function:
+ − 220
+ − 221 @example
+ − 222 (lambda (a b c) (+ a b c))
+ − 223 @end example
+ − 224
+ − 225 @noindent
+ − 226 We can call this function by writing it as the @sc{car} of an
+ − 227 expression, like this:
+ − 228
+ − 229 @example
+ − 230 @group
+ − 231 ((lambda (a b c) (+ a b c))
+ − 232 1 2 3)
+ − 233 @end group
+ − 234 @end example
+ − 235
+ − 236 @noindent
+ − 237 This call evaluates the body of the lambda expression with the variable
+ − 238 @code{a} bound to 1, @code{b} bound to 2, and @code{c} bound to 3.
+ − 239 Evaluation of the body adds these three numbers, producing the result 6;
+ − 240 therefore, this call to the function returns the value 6.
+ − 241
+ − 242 Note that the arguments can be the results of other function calls, as in
+ − 243 this example:
+ − 244
+ − 245 @example
+ − 246 @group
+ − 247 ((lambda (a b c) (+ a b c))
+ − 248 1 (* 2 3) (- 5 4))
+ − 249 @end group
+ − 250 @end example
+ − 251
+ − 252 @noindent
+ − 253 This evaluates the arguments @code{1}, @code{(* 2 3)}, and @code{(- 5
+ − 254 4)} from left to right. Then it applies the lambda expression to the
+ − 255 argument values 1, 6 and 1 to produce the value 8.
+ − 256
+ − 257 It is not often useful to write a lambda expression as the @sc{car} of
+ − 258 a form in this way. You can get the same result, of making local
+ − 259 variables and giving them values, using the special form @code{let}
+ − 260 (@pxref{Local Variables}). And @code{let} is clearer and easier to use.
+ − 261 In practice, lambda expressions are either stored as the function
+ − 262 definitions of symbols, to produce named functions, or passed as
+ − 263 arguments to other functions (@pxref{Anonymous Functions}).
+ − 264
+ − 265 However, calls to explicit lambda expressions were very useful in the
+ − 266 old days of Lisp, before the special form @code{let} was invented. At
+ − 267 that time, they were the only way to bind and initialize local
+ − 268 variables.
+ − 269
+ − 270 @node Argument List
+ − 271 @subsection Advanced Features of Argument Lists
+ − 272 @kindex wrong-number-of-arguments
+ − 273 @cindex argument binding
+ − 274 @cindex binding arguments
+ − 275
+ − 276 Our simple sample function, @code{(lambda (a b c) (+ a b c))},
+ − 277 specifies three argument variables, so it must be called with three
+ − 278 arguments: if you try to call it with only two arguments or four
+ − 279 arguments, you get a @code{wrong-number-of-arguments} error.
+ − 280
+ − 281 It is often convenient to write a function that allows certain
+ − 282 arguments to be omitted. For example, the function @code{substring}
+ − 283 accepts three arguments---a string, the start index and the end
+ − 284 index---but the third argument defaults to the @var{length} of the
+ − 285 string if you omit it. It is also convenient for certain functions to
+ − 286 accept an indefinite number of arguments, as the functions @code{list}
+ − 287 and @code{+} do.
+ − 288
+ − 289 @cindex optional arguments
+ − 290 @cindex rest arguments
+ − 291 @kindex &optional
+ − 292 @kindex &rest
+ − 293 To specify optional arguments that may be omitted when a function
+ − 294 is called, simply include the keyword @code{&optional} before the optional
+ − 295 arguments. To specify a list of zero or more extra arguments, include the
+ − 296 keyword @code{&rest} before one final argument.
+ − 297
+ − 298 Thus, the complete syntax for an argument list is as follows:
+ − 299
+ − 300 @example
+ − 301 @group
+ − 302 (@var{required-vars}@dots{}
+ − 303 @r{[}&optional @var{optional-vars}@dots{}@r{]}
+ − 304 @r{[}&rest @var{rest-var}@r{]})
+ − 305 @end group
+ − 306 @end example
+ − 307
+ − 308 @noindent
+ − 309 The square brackets indicate that the @code{&optional} and @code{&rest}
+ − 310 clauses, and the variables that follow them, are optional.
+ − 311
+ − 312 A call to the function requires one actual argument for each of the
+ − 313 @var{required-vars}. There may be actual arguments for zero or more of
+ − 314 the @var{optional-vars}, and there cannot be any actual arguments beyond
+ − 315 that unless the lambda list uses @code{&rest}. In that case, there may
+ − 316 be any number of extra actual arguments.
+ − 317
+ − 318 If actual arguments for the optional and rest variables are omitted,
+ − 319 then they always default to @code{nil}. There is no way for the
+ − 320 function to distinguish between an explicit argument of @code{nil} and
+ − 321 an omitted argument. However, the body of the function is free to
+ − 322 consider @code{nil} an abbreviation for some other meaningful value.
+ − 323 This is what @code{substring} does; @code{nil} as the third argument to
+ − 324 @code{substring} means to use the length of the string supplied.
+ − 325
+ − 326 @cindex CL note---default optional arg
+ − 327 @quotation
+ − 328 @b{Common Lisp note:} Common Lisp allows the function to specify what
+ − 329 default value to use when an optional argument is omitted; XEmacs Lisp
+ − 330 always uses @code{nil}.
+ − 331 @end quotation
+ − 332
+ − 333 For example, an argument list that looks like this:
+ − 334
+ − 335 @example
+ − 336 (a b &optional c d &rest e)
+ − 337 @end example
+ − 338
+ − 339 @noindent
+ − 340 binds @code{a} and @code{b} to the first two actual arguments, which are
+ − 341 required. If one or two more arguments are provided, @code{c} and
+ − 342 @code{d} are bound to them respectively; any arguments after the first
+ − 343 four are collected into a list and @code{e} is bound to that list. If
+ − 344 there are only two arguments, @code{c} is @code{nil}; if two or three
+ − 345 arguments, @code{d} is @code{nil}; if four arguments or fewer, @code{e}
+ − 346 is @code{nil}.
+ − 347
+ − 348 There is no way to have required arguments following optional
+ − 349 ones---it would not make sense. To see why this must be so, suppose
+ − 350 that @code{c} in the example were optional and @code{d} were required.
+ − 351 Suppose three actual arguments are given; which variable would the third
+ − 352 argument be for? Similarly, it makes no sense to have any more
+ − 353 arguments (either required or optional) after a @code{&rest} argument.
+ − 354
+ − 355 Here are some examples of argument lists and proper calls:
+ − 356
+ − 357 @smallexample
+ − 358 ((lambda (n) (1+ n)) ; @r{One required:}
+ − 359 1) ; @r{requires exactly one argument.}
+ − 360 @result{} 2
+ − 361 ((lambda (n &optional n1) ; @r{One required and one optional:}
+ − 362 (if n1 (+ n n1) (1+ n))) ; @r{1 or 2 arguments.}
+ − 363 1 2)
+ − 364 @result{} 3
+ − 365 ((lambda (n &rest ns) ; @r{One required and one rest:}
+ − 366 (+ n (apply '+ ns))) ; @r{1 or more arguments.}
+ − 367 1 2 3 4 5)
+ − 368 @result{} 15
+ − 369 @end smallexample
+ − 370
+ − 371 @node Function Documentation
+ − 372 @subsection Documentation Strings of Functions
+ − 373 @cindex documentation of function
+ − 374
+ − 375 A lambda expression may optionally have a @dfn{documentation string} just
+ − 376 after the lambda list. This string does not affect execution of the
+ − 377 function; it is a kind of comment, but a systematized comment which
+ − 378 actually appears inside the Lisp world and can be used by the XEmacs help
+ − 379 facilities. @xref{Documentation}, for how the @var{documentation-string} is
+ − 380 accessed.
+ − 381
+ − 382 It is a good idea to provide documentation strings for all the
+ − 383 functions in your program, even those that are only called from within
+ − 384 your program. Documentation strings are like comments, except that they
+ − 385 are easier to access.
+ − 386
+ − 387 The first line of the documentation string should stand on its own,
+ − 388 because @code{apropos} displays just this first line. It should consist
+ − 389 of one or two complete sentences that summarize the function's purpose.
+ − 390
+ − 391 The start of the documentation string is usually indented in the source file,
+ − 392 but since these spaces come before the starting double-quote, they are not part of
+ − 393 the string. Some people make a practice of indenting any additional
+ − 394 lines of the string so that the text lines up in the program source.
+ − 395 @emph{This is a mistake.} The indentation of the following lines is
+ − 396 inside the string; what looks nice in the source code will look ugly
+ − 397 when displayed by the help commands.
+ − 398
+ − 399 You may wonder how the documentation string could be optional, since
+ − 400 there are required components of the function that follow it (the body).
+ − 401 Since evaluation of a string returns that string, without any side effects,
+ − 402 it has no effect if it is not the last form in the body. Thus, in
+ − 403 practice, there is no confusion between the first form of the body and the
+ − 404 documentation string; if the only body form is a string then it serves both
+ − 405 as the return value and as the documentation.
+ − 406
+ − 407 @node Function Names
+ − 408 @section Naming a Function
+ − 409 @cindex function definition
+ − 410 @cindex named function
+ − 411 @cindex function name
+ − 412
+ − 413 In most computer languages, every function has a name; the idea of a
+ − 414 function without a name is nonsensical. In Lisp, a function in the
+ − 415 strictest sense has no name. It is simply a list whose first element is
+ − 416 @code{lambda}, or a primitive subr-object.
+ − 417
+ − 418 However, a symbol can serve as the name of a function. This happens
+ − 419 when you put the function in the symbol's @dfn{function cell}
+ − 420 (@pxref{Symbol Components}). Then the symbol itself becomes a valid,
+ − 421 callable function, equivalent to the list or subr-object that its
+ − 422 function cell refers to. The contents of the function cell are also
+ − 423 called the symbol's @dfn{function definition}. The procedure of using a
+ − 424 symbol's function definition in place of the symbol is called
+ − 425 @dfn{symbol function indirection}; see @ref{Function Indirection}.
+ − 426
+ − 427 In practice, nearly all functions are given names in this way and
+ − 428 referred to through their names. For example, the symbol @code{car} works
+ − 429 as a function and does what it does because the primitive subr-object
+ − 430 @code{#<subr car>} is stored in its function cell.
+ − 431
+ − 432 We give functions names because it is convenient to refer to them by
+ − 433 their names in Lisp expressions. For primitive subr-objects such as
+ − 434 @code{#<subr car>}, names are the only way you can refer to them: there
+ − 435 is no read syntax for such objects. For functions written in Lisp, the
+ − 436 name is more convenient to use in a call than an explicit lambda
+ − 437 expression. Also, a function with a name can refer to itself---it can
+ − 438 be recursive. Writing the function's name in its own definition is much
+ − 439 more convenient than making the function definition point to itself
+ − 440 (something that is not impossible but that has various disadvantages in
+ − 441 practice).
+ − 442
+ − 443 We often identify functions with the symbols used to name them. For
+ − 444 example, we often speak of ``the function @code{car}'', not
+ − 445 distinguishing between the symbol @code{car} and the primitive
+ − 446 subr-object that is its function definition. For most purposes, there
+ − 447 is no need to distinguish.
+ − 448
+ − 449 Even so, keep in mind that a function need not have a unique name. While
+ − 450 a given function object @emph{usually} appears in the function cell of only
+ − 451 one symbol, this is just a matter of convenience. It is easy to store
+ − 452 it in several symbols using @code{fset}; then each of the symbols is
+ − 453 equally well a name for the same function.
+ − 454
+ − 455 A symbol used as a function name may also be used as a variable;
+ − 456 these two uses of a symbol are independent and do not conflict.
+ − 457
+ − 458 @node Defining Functions
+ − 459 @section Defining Functions
+ − 460 @cindex defining a function
+ − 461
+ − 462 We usually give a name to a function when it is first created. This
+ − 463 is called @dfn{defining a function}, and it is done with the
+ − 464 @code{defun} special form.
+ − 465
+ − 466 @defspec defun name argument-list body-forms
+ − 467 @code{defun} is the usual way to define new Lisp functions. It
+ − 468 defines the symbol @var{name} as a function that looks like this:
+ − 469
+ − 470 @example
+ − 471 (lambda @var{argument-list} . @var{body-forms})
+ − 472 @end example
+ − 473
+ − 474 @code{defun} stores this lambda expression in the function cell of
+ − 475 @var{name}. It returns the value @var{name}, but usually we ignore this
+ − 476 value.
+ − 477
+ − 478 As described previously (@pxref{Lambda Expressions}),
+ − 479 @var{argument-list} is a list of argument names and may include the
+ − 480 keywords @code{&optional} and @code{&rest}. Also, the first two forms
+ − 481 in @var{body-forms} may be a documentation string and an interactive
+ − 482 declaration.
+ − 483
+ − 484 There is no conflict if the same symbol @var{name} is also used as a
+ − 485 variable, since the symbol's value cell is independent of the function
+ − 486 cell. @xref{Symbol Components}.
+ − 487
+ − 488 Here are some examples:
+ − 489
+ − 490 @example
+ − 491 @group
+ − 492 (defun foo () 5)
+ − 493 @result{} foo
+ − 494 @end group
+ − 495 @group
+ − 496 (foo)
+ − 497 @result{} 5
+ − 498 @end group
+ − 499
+ − 500 @group
+ − 501 (defun bar (a &optional b &rest c)
+ − 502 (list a b c))
+ − 503 @result{} bar
+ − 504 @end group
+ − 505 @group
+ − 506 (bar 1 2 3 4 5)
+ − 507 @result{} (1 2 (3 4 5))
+ − 508 @end group
+ − 509 @group
+ − 510 (bar 1)
+ − 511 @result{} (1 nil nil)
+ − 512 @end group
+ − 513 @group
+ − 514 (bar)
+ − 515 @error{} Wrong number of arguments.
+ − 516 @end group
+ − 517
+ − 518 @group
+ − 519 (defun capitalize-backwards ()
+ − 520 "Upcase the last letter of a word."
+ − 521 (interactive)
+ − 522 (backward-word 1)
+ − 523 (forward-word 1)
+ − 524 (backward-char 1)
+ − 525 (capitalize-word 1))
+ − 526 @result{} capitalize-backwards
+ − 527 @end group
+ − 528 @end example
+ − 529
+ − 530 Be careful not to redefine existing functions unintentionally.
+ − 531 @code{defun} redefines even primitive functions such as @code{car}
+ − 532 without any hesitation or notification. Redefining a function already
+ − 533 defined is often done deliberately, and there is no way to distinguish
+ − 534 deliberate redefinition from unintentional redefinition.
+ − 535 @end defspec
+ − 536
+ − 537 @defun define-function name definition
+ − 538 @defunx defalias name definition
+ − 539 These equivalent special forms define the symbol @var{name} as a
+ − 540 function, with definition @var{definition} (which can be any valid Lisp
+ − 541 function).
+ − 542
+ − 543 The proper place to use @code{define-function} or @code{defalias} is
+ − 544 where a specific function name is being defined---especially where that
+ − 545 name appears explicitly in the source file being loaded. This is
+ − 546 because @code{define-function} and @code{defalias} record which file
+ − 547 defined the function, just like @code{defun}.
+ − 548 (@pxref{Unloading}).
+ − 549
+ − 550 By contrast, in programs that manipulate function definitions for other
+ − 551 purposes, it is better to use @code{fset}, which does not keep such
+ − 552 records.
+ − 553 @end defun
+ − 554
+ − 555 See also @code{defsubst}, which defines a function like @code{defun}
+ − 556 and tells the Lisp compiler to open-code it. @xref{Inline Functions}.
+ − 557
+ − 558 @node Calling Functions
+ − 559 @section Calling Functions
+ − 560 @cindex function invocation
+ − 561 @cindex calling a function
+ − 562
+ − 563 Defining functions is only half the battle. Functions don't do
+ − 564 anything until you @dfn{call} them, i.e., tell them to run. Calling a
+ − 565 function is also known as @dfn{invocation}.
+ − 566
+ − 567 The most common way of invoking a function is by evaluating a list.
+ − 568 For example, evaluating the list @code{(concat "a" "b")} calls the
+ − 569 function @code{concat} with arguments @code{"a"} and @code{"b"}.
+ − 570 @xref{Evaluation}, for a description of evaluation.
+ − 571
+ − 572 When you write a list as an expression in your program, the function
+ − 573 name is part of the program. This means that you choose which function
+ − 574 to call, and how many arguments to give it, when you write the program.
+ − 575 Usually that's just what you want. Occasionally you need to decide at
+ − 576 run time which function to call. To do that, use the functions
+ − 577 @code{funcall} and @code{apply}.
+ − 578
+ − 579 @defun funcall function &rest arguments
+ − 580 @code{funcall} calls @var{function} with @var{arguments}, and returns
+ − 581 whatever @var{function} returns.
+ − 582
+ − 583 Since @code{funcall} is a function, all of its arguments, including
+ − 584 @var{function}, are evaluated before @code{funcall} is called. This
+ − 585 means that you can use any expression to obtain the function to be
+ − 586 called. It also means that @code{funcall} does not see the expressions
+ − 587 you write for the @var{arguments}, only their values. These values are
+ − 588 @emph{not} evaluated a second time in the act of calling @var{function};
+ − 589 @code{funcall} enters the normal procedure for calling a function at the
+ − 590 place where the arguments have already been evaluated.
+ − 591
+ − 592 The argument @var{function} must be either a Lisp function or a
+ − 593 primitive function. Special forms and macros are not allowed, because
+ − 594 they make sense only when given the ``unevaluated'' argument
+ − 595 expressions. @code{funcall} cannot provide these because, as we saw
+ − 596 above, it never knows them in the first place.
+ − 597
+ − 598 @example
+ − 599 @group
+ − 600 (setq f 'list)
+ − 601 @result{} list
+ − 602 @end group
+ − 603 @group
+ − 604 (funcall f 'x 'y 'z)
+ − 605 @result{} (x y z)
+ − 606 @end group
+ − 607 @group
+ − 608 (funcall f 'x 'y '(z))
+ − 609 @result{} (x y (z))
+ − 610 @end group
+ − 611 @group
+ − 612 (funcall 'and t nil)
+ − 613 @error{} Invalid function: #<subr and>
+ − 614 @end group
+ − 615 @end example
+ − 616
+ − 617 Compare these example with the examples of @code{apply}.
+ − 618 @end defun
+ − 619
+ − 620 @defun apply function &rest arguments
+ − 621 @code{apply} calls @var{function} with @var{arguments}, just like
+ − 622 @code{funcall} but with one difference: the last of @var{arguments} is a
+ − 623 list of arguments to give to @var{function}, rather than a single
+ − 624 argument. We also say that @code{apply} @dfn{spreads} this list so that
+ − 625 each individual element becomes an argument.
+ − 626
+ − 627 @code{apply} returns the result of calling @var{function}. As with
+ − 628 @code{funcall}, @var{function} must either be a Lisp function or a
+ − 629 primitive function; special forms and macros do not make sense in
+ − 630 @code{apply}.
+ − 631
+ − 632 @example
+ − 633 @group
+ − 634 (setq f 'list)
+ − 635 @result{} list
+ − 636 @end group
+ − 637 @group
+ − 638 (apply f 'x 'y 'z)
+ − 639 @error{} Wrong type argument: listp, z
+ − 640 @end group
+ − 641 @group
+ − 642 (apply '+ 1 2 '(3 4))
+ − 643 @result{} 10
+ − 644 @end group
+ − 645 @group
+ − 646 (apply '+ '(1 2 3 4))
+ − 647 @result{} 10
+ − 648 @end group
+ − 649
+ − 650 @group
+ − 651 (apply 'append '((a b c) nil (x y z) nil))
+ − 652 @result{} (a b c x y z)
+ − 653 @end group
+ − 654 @end example
+ − 655
+ − 656 For an interesting example of using @code{apply}, see the description of
+ − 657 @code{mapcar}, in @ref{Mapping Functions}.
+ − 658 @end defun
+ − 659
+ − 660 @cindex functionals
+ − 661 It is common for Lisp functions to accept functions as arguments or
+ − 662 find them in data structures (especially in hook variables and property
+ − 663 lists) and call them using @code{funcall} or @code{apply}. Functions
+ − 664 that accept function arguments are often called @dfn{functionals}.
+ − 665
+ − 666 Sometimes, when you call a functional, it is useful to supply a no-op
+ − 667 function as the argument. Here are two different kinds of no-op
+ − 668 function:
+ − 669
+ − 670 @defun identity arg
+ − 671 This function returns @var{arg} and has no side effects.
+ − 672 @end defun
+ − 673
444
+ − 674 @deffn Command ignore &rest args
428
+ − 675 This function ignores any arguments and returns @code{nil}.
444
+ − 676 @end deffn
428
+ − 677
+ − 678 @node Mapping Functions
+ − 679 @section Mapping Functions
+ − 680 @cindex mapping functions
+ − 681
+ − 682 A @dfn{mapping function} applies a given function to each element of a
434
+ − 683 list or other collection. XEmacs Lisp has several such functions;
428
+ − 684 @code{mapcar} and @code{mapconcat}, which scan a list, are described
434
+ − 685 here. @xref{Creating Symbols}, for the function @code{mapatoms} which
+ − 686 maps over the symbols in an obarray.
+ − 687
+ − 688 Mapping functions should never modify the sequence being mapped over.
+ − 689 The results are unpredictable.
428
+ − 690
+ − 691 @defun mapcar function sequence
+ − 692 @code{mapcar} applies @var{function} to each element of @var{sequence}
+ − 693 in turn, and returns a list of the results.
+ − 694
434
+ − 695 The argument @var{sequence} can be any kind of sequence; that is, a
+ − 696 list, a vector, a bit vector, or a string. The result is always a list.
+ − 697 The length of the result is the same as the length of @var{sequence}.
428
+ − 698
+ − 699 @smallexample
+ − 700 @group
+ − 701 @exdent @r{For example:}
+ − 702
+ − 703 (mapcar 'car '((a b) (c d) (e f)))
+ − 704 @result{} (a c e)
+ − 705 (mapcar '1+ [1 2 3])
+ − 706 @result{} (2 3 4)
+ − 707 (mapcar 'char-to-string "abc")
+ − 708 @result{} ("a" "b" "c")
+ − 709 @end group
+ − 710
+ − 711 @group
+ − 712 ;; @r{Call each function in @code{my-hooks}.}
+ − 713 (mapcar 'funcall my-hooks)
+ − 714 @end group
+ − 715
+ − 716 @group
+ − 717 (defun mapcar* (f &rest args)
+ − 718 "Apply FUNCTION to successive cars of all ARGS.
+ − 719 Return the list of results."
+ − 720 ;; @r{If no list is exhausted,}
444
+ − 721 (if (not (memq 'nil args))
428
+ − 722 ;; @r{apply function to @sc{car}s.}
444
+ − 723 (cons (apply f (mapcar 'car args))
+ − 724 (apply 'mapcar* f
428
+ − 725 ;; @r{Recurse for rest of elements.}
+ − 726 (mapcar 'cdr args)))))
+ − 727 @end group
+ − 728
+ − 729 @group
+ − 730 (mapcar* 'cons '(a b c) '(1 2 3 4))
+ − 731 @result{} ((a . 1) (b . 2) (c . 3))
+ − 732 @end group
+ − 733 @end smallexample
+ − 734 @end defun
+ − 735
+ − 736 @defun mapconcat function sequence separator
+ − 737 @code{mapconcat} applies @var{function} to each element of
+ − 738 @var{sequence}: the results, which must be strings, are concatenated.
+ − 739 Between each pair of result strings, @code{mapconcat} inserts the string
+ − 740 @var{separator}. Usually @var{separator} contains a space or comma or
+ − 741 other suitable punctuation.
+ − 742
+ − 743 The argument @var{function} must be a function that can take one
434
+ − 744 argument and return a string. The argument @var{sequence} can be any
+ − 745 kind of sequence; that is, a list, a vector, a bit vector, or a string.
444
+ − 746
428
+ − 747 @smallexample
+ − 748 @group
+ − 749 (mapconcat 'symbol-name
+ − 750 '(The cat in the hat)
+ − 751 " ")
+ − 752 @result{} "The cat in the hat"
+ − 753 @end group
+ − 754
+ − 755 @group
+ − 756 (mapconcat (function (lambda (x) (format "%c" (1+ x))))
+ − 757 "HAL-8000"
+ − 758 "")
+ − 759 @result{} "IBM.9111"
+ − 760 @end group
+ − 761 @end smallexample
+ − 762 @end defun
+ − 763
+ − 764 @node Anonymous Functions
+ − 765 @section Anonymous Functions
+ − 766 @cindex anonymous function
+ − 767
+ − 768 In Lisp, a function is a list that starts with @code{lambda}, a
+ − 769 byte-code function compiled from such a list, or alternatively a
+ − 770 primitive subr-object; names are ``extra''. Although usually functions
+ − 771 are defined with @code{defun} and given names at the same time, it is
+ − 772 occasionally more concise to use an explicit lambda expression---an
+ − 773 anonymous function. Such a list is valid wherever a function name is.
+ − 774
+ − 775 Any method of creating such a list makes a valid function. Even this:
+ − 776
+ − 777 @smallexample
+ − 778 @group
+ − 779 (setq silly (append '(lambda (x)) (list (list '+ (* 3 4) 'x))))
+ − 780 @result{} (lambda (x) (+ 12 x))
+ − 781 @end group
+ − 782 @end smallexample
+ − 783
+ − 784 @noindent
+ − 785 This computes a list that looks like @code{(lambda (x) (+ 12 x))} and
+ − 786 makes it the value (@emph{not} the function definition!) of
+ − 787 @code{silly}.
+ − 788
+ − 789 Here is how we might call this function:
+ − 790
+ − 791 @example
+ − 792 @group
+ − 793 (funcall silly 1)
+ − 794 @result{} 13
+ − 795 @end group
+ − 796 @end example
+ − 797
+ − 798 @noindent
+ − 799 (It does @emph{not} work to write @code{(silly 1)}, because this function
+ − 800 is not the @emph{function definition} of @code{silly}. We have not given
+ − 801 @code{silly} any function definition, just a value as a variable.)
+ − 802
+ − 803 Most of the time, anonymous functions are constants that appear in
+ − 804 your program. For example, you might want to pass one as an argument
+ − 805 to the function @code{mapcar}, which applies any given function to each
+ − 806 element of a list. Here we pass an anonymous function that multiplies
+ − 807 a number by two:
+ − 808
+ − 809 @example
+ − 810 @group
+ − 811 (defun double-each (list)
+ − 812 (mapcar '(lambda (x) (* 2 x)) list))
+ − 813 @result{} double-each
+ − 814 @end group
+ − 815 @group
+ − 816 (double-each '(2 11))
+ − 817 @result{} (4 22)
+ − 818 @end group
+ − 819 @end example
+ − 820
+ − 821 @noindent
+ − 822 In such cases, we usually use the special form @code{function} instead
+ − 823 of simple quotation to quote the anonymous function.
+ − 824
+ − 825 @defspec function function-object
+ − 826 @cindex function quoting
+ − 827 This special form returns @var{function-object} without evaluating it.
+ − 828 In this, it is equivalent to @code{quote}. However, it serves as a
+ − 829 note to the XEmacs Lisp compiler that @var{function-object} is intended
+ − 830 to be used only as a function, and therefore can safely be compiled.
+ − 831 Contrast this with @code{quote}, in @ref{Quoting}.
+ − 832 @end defspec
+ − 833
+ − 834 Using @code{function} instead of @code{quote} makes a difference
+ − 835 inside a function or macro that you are going to compile. For example:
+ − 836
+ − 837 @example
+ − 838 @group
+ − 839 (defun double-each (list)
+ − 840 (mapcar (function (lambda (x) (* 2 x))) list))
+ − 841 @result{} double-each
+ − 842 @end group
+ − 843 @group
+ − 844 (double-each '(2 11))
+ − 845 @result{} (4 22)
+ − 846 @end group
+ − 847 @end example
+ − 848
+ − 849 @noindent
+ − 850 If this definition of @code{double-each} is compiled, the anonymous
+ − 851 function is compiled as well. By contrast, in the previous definition
+ − 852 where ordinary @code{quote} is used, the argument passed to
+ − 853 @code{mapcar} is the precise list shown:
+ − 854
+ − 855 @example
+ − 856 (lambda (x) (* x 2))
+ − 857 @end example
+ − 858
+ − 859 @noindent
+ − 860 The Lisp compiler cannot assume this list is a function, even though it
+ − 861 looks like one, since it does not know what @code{mapcar} does with the
+ − 862 list. Perhaps @code{mapcar} will check that the @sc{car} of the third
+ − 863 element is the symbol @code{*}! The advantage of @code{function} is
+ − 864 that it tells the compiler to go ahead and compile the constant
+ − 865 function.
+ − 866
+ − 867 We sometimes write @code{function} instead of @code{quote} when
+ − 868 quoting the name of a function, but this usage is just a sort of
+ − 869 comment.
+ − 870
+ − 871 @example
+ − 872 (function @var{symbol}) @equiv{} (quote @var{symbol}) @equiv{} '@var{symbol}
+ − 873 @end example
+ − 874
+ − 875 See @code{documentation} in @ref{Accessing Documentation}, for a
+ − 876 realistic example using @code{function} and an anonymous function.
+ − 877
+ − 878 @node Function Cells
+ − 879 @section Accessing Function Cell Contents
+ − 880
+ − 881 The @dfn{function definition} of a symbol is the object stored in the
+ − 882 function cell of the symbol. The functions described here access, test,
+ − 883 and set the function cell of symbols.
+ − 884
+ − 885 See also the function @code{indirect-function} in @ref{Function
+ − 886 Indirection}.
+ − 887
+ − 888 @defun symbol-function symbol
+ − 889 @kindex void-function
+ − 890 This returns the object in the function cell of @var{symbol}. If the
+ − 891 symbol's function cell is void, a @code{void-function} error is
+ − 892 signaled.
+ − 893
+ − 894 This function does not check that the returned object is a legitimate
+ − 895 function.
+ − 896
+ − 897 @example
+ − 898 @group
+ − 899 (defun bar (n) (+ n 2))
+ − 900 @result{} bar
+ − 901 @end group
+ − 902 @group
+ − 903 (symbol-function 'bar)
+ − 904 @result{} (lambda (n) (+ n 2))
+ − 905 @end group
+ − 906 @group
+ − 907 (fset 'baz 'bar)
+ − 908 @result{} bar
+ − 909 @end group
+ − 910 @group
+ − 911 (symbol-function 'baz)
+ − 912 @result{} bar
+ − 913 @end group
+ − 914 @end example
+ − 915 @end defun
+ − 916
+ − 917 @cindex void function cell
+ − 918 If you have never given a symbol any function definition, we say that
+ − 919 that symbol's function cell is @dfn{void}. In other words, the function
+ − 920 cell does not have any Lisp object in it. If you try to call such a symbol
+ − 921 as a function, it signals a @code{void-function} error.
+ − 922
+ − 923 Note that void is not the same as @code{nil} or the symbol
+ − 924 @code{void}. The symbols @code{nil} and @code{void} are Lisp objects,
+ − 925 and can be stored into a function cell just as any other object can be
+ − 926 (and they can be valid functions if you define them in turn with
+ − 927 @code{defun}). A void function cell contains no object whatsoever.
+ − 928
+ − 929 You can test the voidness of a symbol's function definition with
+ − 930 @code{fboundp}. After you have given a symbol a function definition, you
+ − 931 can make it void once more using @code{fmakunbound}.
+ − 932
+ − 933 @defun fboundp symbol
444
+ − 934 This function returns @code{t} if @var{symbol} has an object in its
428
+ − 935 function cell, @code{nil} otherwise. It does not check that the object
+ − 936 is a legitimate function.
+ − 937 @end defun
+ − 938
+ − 939 @defun fmakunbound symbol
+ − 940 This function makes @var{symbol}'s function cell void, so that a
+ − 941 subsequent attempt to access this cell will cause a @code{void-function}
+ − 942 error. (See also @code{makunbound}, in @ref{Local Variables}.)
+ − 943
+ − 944 @example
+ − 945 @group
+ − 946 (defun foo (x) x)
+ − 947 @result{} x
+ − 948 @end group
+ − 949 @group
+ − 950 (foo 1)
+ − 951 @result{}1
+ − 952 @end group
+ − 953 @group
+ − 954 (fmakunbound 'foo)
+ − 955 @result{} x
+ − 956 @end group
+ − 957 @group
+ − 958 (foo 1)
+ − 959 @error{} Symbol's function definition is void: foo
+ − 960 @end group
+ − 961 @end example
+ − 962 @end defun
+ − 963
+ − 964 @defun fset symbol object
+ − 965 This function stores @var{object} in the function cell of @var{symbol}.
+ − 966 The result is @var{object}. Normally @var{object} should be a function
+ − 967 or the name of a function, but this is not checked.
+ − 968
+ − 969 There are three normal uses of this function:
+ − 970
+ − 971 @itemize @bullet
+ − 972 @item
+ − 973 Copying one symbol's function definition to another. (In other words,
+ − 974 making an alternate name for a function.)
+ − 975
+ − 976 @item
+ − 977 Giving a symbol a function definition that is not a list and therefore
+ − 978 cannot be made with @code{defun}. For example, you can use @code{fset}
444
+ − 979 to give a symbol @var{symbol1} a function definition which is another symbol
+ − 980 @var{symbol2}; then @var{symbol1} serves as an alias for whatever definition
+ − 981 @var{symbol2} presently has.
428
+ − 982
+ − 983 @item
+ − 984 In constructs for defining or altering functions. If @code{defun}
+ − 985 were not a primitive, it could be written in Lisp (as a macro) using
+ − 986 @code{fset}.
+ − 987 @end itemize
+ − 988
+ − 989 Here are examples of the first two uses:
+ − 990
+ − 991 @example
+ − 992 @group
+ − 993 ;; @r{Give @code{first} the same definition @code{car} has.}
+ − 994 (fset 'first (symbol-function 'car))
+ − 995 @result{} #<subr car>
+ − 996 @end group
+ − 997 @group
+ − 998 (first '(1 2 3))
+ − 999 @result{} 1
+ − 1000 @end group
+ − 1001
+ − 1002 @group
+ − 1003 ;; @r{Make the symbol @code{car} the function definition of @code{xfirst}.}
+ − 1004 (fset 'xfirst 'car)
+ − 1005 @result{} car
+ − 1006 @end group
+ − 1007 @group
+ − 1008 (xfirst '(1 2 3))
+ − 1009 @result{} 1
+ − 1010 @end group
+ − 1011 @group
+ − 1012 (symbol-function 'xfirst)
+ − 1013 @result{} car
+ − 1014 @end group
+ − 1015 @group
+ − 1016 (symbol-function (symbol-function 'xfirst))
+ − 1017 @result{} #<subr car>
+ − 1018 @end group
+ − 1019
+ − 1020 @group
+ − 1021 ;; @r{Define a named keyboard macro.}
+ − 1022 (fset 'kill-two-lines "\^u2\^k")
+ − 1023 @result{} "\^u2\^k"
+ − 1024 @end group
+ − 1025 @end example
+ − 1026
+ − 1027 See also the related functions @code{define-function} and
+ − 1028 @code{defalias}, in @ref{Defining Functions}.
+ − 1029 @end defun
+ − 1030
+ − 1031 When writing a function that extends a previously defined function,
+ − 1032 the following idiom is sometimes used:
+ − 1033
+ − 1034 @example
+ − 1035 (fset 'old-foo (symbol-function 'foo))
+ − 1036 (defun foo ()
+ − 1037 "Just like old-foo, except more so."
+ − 1038 @group
+ − 1039 (old-foo)
+ − 1040 (more-so))
+ − 1041 @end group
+ − 1042 @end example
+ − 1043
+ − 1044 @noindent
+ − 1045 This does not work properly if @code{foo} has been defined to autoload.
+ − 1046 In such a case, when @code{foo} calls @code{old-foo}, Lisp attempts
+ − 1047 to define @code{old-foo} by loading a file. Since this presumably
+ − 1048 defines @code{foo} rather than @code{old-foo}, it does not produce the
+ − 1049 proper results. The only way to avoid this problem is to make sure the
+ − 1050 file is loaded before moving aside the old definition of @code{foo}.
+ − 1051
+ − 1052 But it is unmodular and unclean, in any case, for a Lisp file to
+ − 1053 redefine a function defined elsewhere.
+ − 1054
+ − 1055 @node Inline Functions
+ − 1056 @section Inline Functions
+ − 1057 @cindex inline functions
+ − 1058
+ − 1059 @findex defsubst
+ − 1060 You can define an @dfn{inline function} by using @code{defsubst} instead
+ − 1061 of @code{defun}. An inline function works just like an ordinary
+ − 1062 function except for one thing: when you compile a call to the function,
+ − 1063 the function's definition is open-coded into the caller.
+ − 1064
+ − 1065 Making a function inline makes explicit calls run faster. But it also
+ − 1066 has disadvantages. For one thing, it reduces flexibility; if you change
+ − 1067 the definition of the function, calls already inlined still use the old
+ − 1068 definition until you recompile them. Since the flexibility of
+ − 1069 redefining functions is an important feature of XEmacs, you should not
+ − 1070 make a function inline unless its speed is really crucial.
+ − 1071
+ − 1072 Another disadvantage is that making a large function inline can increase
+ − 1073 the size of compiled code both in files and in memory. Since the speed
+ − 1074 advantage of inline functions is greatest for small functions, you
+ − 1075 generally should not make large functions inline.
+ − 1076
+ − 1077 It's possible to define a macro to expand into the same code that an
+ − 1078 inline function would execute. But the macro would have a limitation:
+ − 1079 you can use it only explicitly---a macro cannot be called with
+ − 1080 @code{apply}, @code{mapcar} and so on. Also, it takes some work to
+ − 1081 convert an ordinary function into a macro. (@xref{Macros}.) To convert
+ − 1082 it into an inline function is very easy; simply replace @code{defun}
+ − 1083 with @code{defsubst}. Since each argument of an inline function is
+ − 1084 evaluated exactly once, you needn't worry about how many times the
+ − 1085 body uses the arguments, as you do for macros. (@xref{Argument
+ − 1086 Evaluation}.)
+ − 1087
+ − 1088 Inline functions can be used and open-coded later on in the same file,
+ − 1089 following the definition, just like macros.
+ − 1090
+ − 1091 @c Emacs versions prior to 19 did not have inline functions.
+ − 1092
+ − 1093 @node Related Topics
+ − 1094 @section Other Topics Related to Functions
+ − 1095
+ − 1096 Here is a table of several functions that do things related to
+ − 1097 function calling and function definitions. They are documented
+ − 1098 elsewhere, but we provide cross references here.
+ − 1099
+ − 1100 @table @code
+ − 1101 @item apply
+ − 1102 See @ref{Calling Functions}.
+ − 1103
+ − 1104 @item autoload
+ − 1105 See @ref{Autoload}.
+ − 1106
+ − 1107 @item call-interactively
+ − 1108 See @ref{Interactive Call}.
+ − 1109
+ − 1110 @item commandp
+ − 1111 See @ref{Interactive Call}.
+ − 1112
+ − 1113 @item documentation
+ − 1114 See @ref{Accessing Documentation}.
+ − 1115
+ − 1116 @item eval
+ − 1117 See @ref{Eval}.
+ − 1118
+ − 1119 @item funcall
+ − 1120 See @ref{Calling Functions}.
+ − 1121
+ − 1122 @item ignore
+ − 1123 See @ref{Calling Functions}.
+ − 1124
+ − 1125 @item indirect-function
+ − 1126 See @ref{Function Indirection}.
+ − 1127
+ − 1128 @item interactive
+ − 1129 See @ref{Using Interactive}.
+ − 1130
+ − 1131 @item interactive-p
+ − 1132 See @ref{Interactive Call}.
+ − 1133
+ − 1134 @item mapatoms
+ − 1135 See @ref{Creating Symbols}.
+ − 1136
+ − 1137 @item mapcar
+ − 1138 See @ref{Mapping Functions}.
+ − 1139
+ − 1140 @item mapconcat
+ − 1141 See @ref{Mapping Functions}.
+ − 1142
+ − 1143 @item undefined
+ − 1144 See @ref{Key Lookup}.
+ − 1145 @end table
+ − 1146
