|
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
|
|
|
45 specifically to mean a function written in Lisp. Special forms and
|
|
|
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
|
|
|
87 @dfn{built-in} functions or @dfn{subrs}. (Special forms are also
|
|
|
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
|
|
|
104 @item special form
|
|
|
105 A @dfn{special form} is a primitive that is like a function but does not
|
|
|
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
|
|
|
108 several times. Many special forms are described in @ref{Control
|
|
|
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
|
|
|
117 things that special forms can do. @xref{Macros}, for how to define and
|
|
|
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
|
|
|
270 variables and giving them values, using the special form @code{let}
|
|
|
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
|
|
|
277 old days of Lisp, before the special form @code{let} was invented. At
|
|
|
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
|
|
|
475 @code{defun} special form.
|
|
|
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
|
|
|
550 These equivalent special forms define the symbol @var{name} as a
|
|
|
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
|
|
|
604 primitive function. Special forms and macros are not allowed, because
|
|
|
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
|
|
|
640 primitive function; special forms and macros do not make sense in
|
|
|
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
|
|
|
833 In such cases, we usually use the special form @code{function} instead
|
|
|
834 of simple quotation to quote the anonymous function.
|
|
|
835
|
|
|
836 @defspec function function-object
|
|
|
837 @cindex function quoting
|
|
|
838 This special form returns @var{function-object} without evaluating it.
|
|
|
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
|
