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