6455
|
1 @c -*-texinfo-*-
|
|
2 @c This is part of the GNU Emacs Lisp Reference Manual.
|
64889
|
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2002, 2003,
|
68648
|
4 @c 2004, 2005, 2006 Free Software Foundation, Inc.
|
6455
|
5 @c See the file elisp.texi for copying conditions.
|
|
6 @setfilename ../info/functions
|
|
7 @node Functions, Macros, Variables, Top
|
|
8 @chapter Functions
|
|
9
|
|
10 A Lisp program is composed mainly of Lisp functions. This chapter
|
|
11 explains what functions are, how they accept arguments, and how to
|
|
12 define them.
|
|
13
|
|
14 @menu
|
|
15 * What Is a Function:: Lisp functions vs. primitives; terminology.
|
|
16 * Lambda Expressions:: How functions are expressed as Lisp objects.
|
|
17 * Function Names:: A symbol can serve as the name of a function.
|
|
18 * Defining Functions:: Lisp expressions for defining functions.
|
|
19 * Calling Functions:: How to use an existing function.
|
|
20 * Mapping Functions:: Applying a function to each element of a list, etc.
|
49600
|
21 * Anonymous Functions:: Lambda expressions are functions with no names.
|
6455
|
22 * Function Cells:: Accessing or setting the function definition
|
|
23 of a symbol.
|
62096
|
24 * Obsolete Functions:: Declaring functions obsolete.
|
6455
|
25 * Inline Functions:: Defining functions that the compiler will open code.
|
51701
|
26 * Function Safety:: Determining whether a function is safe to call.
|
6455
|
27 * Related Topics:: Cross-references to specific Lisp primitives
|
|
28 that have a special bearing on how functions work.
|
|
29 @end menu
|
|
30
|
|
31 @node What Is a Function
|
|
32 @section What Is a Function?
|
|
33
|
|
34 In a general sense, a function is a rule for carrying on a computation
|
|
35 given several values called @dfn{arguments}. The result of the
|
|
36 computation is called the value of the function. The computation can
|
|
37 also have side effects: lasting changes in the values of variables or
|
|
38 the contents of data structures.
|
|
39
|
|
40 Here are important terms for functions in Emacs Lisp and for other
|
|
41 function-like objects.
|
|
42
|
|
43 @table @dfn
|
|
44 @item function
|
|
45 @cindex function
|
|
46 In Emacs Lisp, a @dfn{function} is anything that can be applied to
|
|
47 arguments in a Lisp program. In some cases, we use it more
|
|
48 specifically to mean a function written in Lisp. Special forms and
|
|
49 macros are not functions.
|
|
50
|
|
51 @item primitive
|
|
52 @cindex primitive
|
|
53 @cindex subr
|
|
54 @cindex built-in function
|
|
55 A @dfn{primitive} is a function callable from Lisp that is written in C,
|
|
56 such as @code{car} or @code{append}. These functions are also called
|
60038
|
57 @dfn{built-in functions}, or @dfn{subrs}. (Special forms are also
|
6455
|
58 considered primitives.)
|
|
59
|
22138
|
60 Usually the reason we implement a function as a primitive is either
|
51701
|
61 because it is fundamental, because it provides a low-level interface
|
|
62 to operating system services, or because it needs to run fast.
|
|
63 Primitives can be modified or added only by changing the C sources and
|
|
64 recompiling the editor. See @ref{Writing Emacs Primitives}.
|
6455
|
65
|
|
66 @item lambda expression
|
|
67 A @dfn{lambda expression} is a function written in Lisp.
|
|
68 These are described in the following section.
|
27193
|
69 @ifnottex
|
6455
|
70 @xref{Lambda Expressions}.
|
27193
|
71 @end ifnottex
|
6455
|
72
|
|
73 @item special form
|
|
74 A @dfn{special form} is a primitive that is like a function but does not
|
|
75 evaluate all of its arguments in the usual way. It may evaluate only
|
|
76 some of the arguments, or may evaluate them in an unusual order, or
|
|
77 several times. Many special forms are described in @ref{Control
|
|
78 Structures}.
|
|
79
|
|
80 @item macro
|
|
81 @cindex macro
|
|
82 A @dfn{macro} is a construct defined in Lisp by the programmer. It
|
|
83 differs from a function in that it translates a Lisp expression that you
|
|
84 write into an equivalent expression to be evaluated instead of the
|
12098
|
85 original expression. Macros enable Lisp programmers to do the sorts of
|
|
86 things that special forms can do. @xref{Macros}, for how to define and
|
|
87 use macros.
|
6455
|
88
|
|
89 @item command
|
|
90 @cindex command
|
|
91 A @dfn{command} is an object that @code{command-execute} can invoke; it
|
|
92 is a possible definition for a key sequence. Some functions are
|
|
93 commands; a function written in Lisp is a command if it contains an
|
|
94 interactive declaration (@pxref{Defining Commands}). Such a function
|
|
95 can be called from Lisp expressions like other functions; in this case,
|
|
96 the fact that the function is a command makes no difference.
|
|
97
|
|
98 Keyboard macros (strings and vectors) are commands also, even though
|
|
99 they are not functions. A symbol is a command if its function
|
|
100 definition is a command; such symbols can be invoked with @kbd{M-x}.
|
|
101 The symbol is a function as well if the definition is a function.
|
68706
|
102 @xref{Interactive Call}.
|
6455
|
103
|
|
104 @item keystroke command
|
|
105 @cindex keystroke command
|
|
106 A @dfn{keystroke command} is a command that is bound to a key sequence
|
|
107 (typically one to three keystrokes). The distinction is made here
|
|
108 merely to avoid confusion with the meaning of ``command'' in non-Emacs
|
|
109 editors; for Lisp programs, the distinction is normally unimportant.
|
|
110
|
|
111 @item byte-code function
|
|
112 A @dfn{byte-code function} is a function that has been compiled by the
|
|
113 byte compiler. @xref{Byte-Code Type}.
|
|
114 @end table
|
|
115
|
22138
|
116 @defun functionp object
|
53483
|
117 This function returns @code{t} if @var{object} is any kind of
|
|
118 function, or a special form, or, recursively, a symbol whose function
|
|
119 definition is a function or special form. (This does not include
|
|
120 macros.)
|
21007
|
121 @end defun
|
|
122
|
53483
|
123 Unlike @code{functionp}, the next three functions do @emph{not}
|
|
124 treat a symbol as its function definition.
|
|
125
|
6455
|
126 @defun subrp object
|
|
127 This function returns @code{t} if @var{object} is a built-in function
|
|
128 (i.e., a Lisp primitive).
|
|
129
|
|
130 @example
|
|
131 @group
|
|
132 (subrp 'message) ; @r{@code{message} is a symbol,}
|
|
133 @result{} nil ; @r{not a subr object.}
|
|
134 @end group
|
|
135 @group
|
|
136 (subrp (symbol-function 'message))
|
|
137 @result{} t
|
|
138 @end group
|
|
139 @end example
|
|
140 @end defun
|
|
141
|
|
142 @defun byte-code-function-p object
|
|
143 This function returns @code{t} if @var{object} is a byte-code
|
|
144 function. For example:
|
|
145
|
|
146 @example
|
|
147 @group
|
|
148 (byte-code-function-p (symbol-function 'next-line))
|
|
149 @result{} t
|
|
150 @end group
|
|
151 @end example
|
|
152 @end defun
|
|
153
|
33999
|
154 @defun subr-arity subr
|
|
155 This function provides information about the argument list of a
|
|
156 primitive, @var{subr}. The returned value is a pair
|
|
157 @code{(@var{min} . @var{max})}. @var{min} is the minimum number of
|
|
158 args. @var{max} is the maximum number or the symbol @code{many}, for a
|
|
159 function with @code{&rest} arguments, or the symbol @code{unevalled} if
|
|
160 @var{subr} is a special form.
|
|
161 @end defun
|
|
162
|
6455
|
163 @node Lambda Expressions
|
|
164 @section Lambda Expressions
|
|
165 @cindex lambda expression
|
|
166
|
|
167 A function written in Lisp is a list that looks like this:
|
|
168
|
|
169 @example
|
|
170 (lambda (@var{arg-variables}@dots{})
|
|
171 @r{[}@var{documentation-string}@r{]}
|
|
172 @r{[}@var{interactive-declaration}@r{]}
|
|
173 @var{body-forms}@dots{})
|
|
174 @end example
|
|
175
|
|
176 @noindent
|
12098
|
177 Such a list is called a @dfn{lambda expression}. In Emacs Lisp, it
|
|
178 actually is valid as an expression---it evaluates to itself. In some
|
|
179 other Lisp dialects, a lambda expression is not a valid expression at
|
|
180 all. In either case, its main use is not to be evaluated as an
|
|
181 expression, but to be called as a function.
|
6455
|
182
|
|
183 @menu
|
|
184 * Lambda Components:: The parts of a lambda expression.
|
|
185 * Simple Lambda:: A simple example.
|
|
186 * Argument List:: Details and special features of argument lists.
|
|
187 * Function Documentation:: How to put documentation in a function.
|
|
188 @end menu
|
|
189
|
|
190 @node Lambda Components
|
|
191 @subsection Components of a Lambda Expression
|
|
192
|
27193
|
193 @ifnottex
|
6455
|
194
|
|
195 A function written in Lisp (a ``lambda expression'') is a list that
|
|
196 looks like this:
|
|
197
|
|
198 @example
|
|
199 (lambda (@var{arg-variables}@dots{})
|
|
200 [@var{documentation-string}]
|
|
201 [@var{interactive-declaration}]
|
|
202 @var{body-forms}@dots{})
|
|
203 @end example
|
27193
|
204 @end ifnottex
|
6455
|
205
|
|
206 @cindex lambda list
|
|
207 The first element of a lambda expression is always the symbol
|
|
208 @code{lambda}. This indicates that the list represents a function. The
|
|
209 reason functions are defined to start with @code{lambda} is so that
|
|
210 other lists, intended for other uses, will not accidentally be valid as
|
|
211 functions.
|
|
212
|
21007
|
213 The second element is a list of symbols---the argument variable names.
|
6455
|
214 This is called the @dfn{lambda list}. When a Lisp function is called,
|
|
215 the argument values are matched up against the variables in the lambda
|
|
216 list, which are given local bindings with the values provided.
|
|
217 @xref{Local Variables}.
|
|
218
|
7193
|
219 The documentation string is a Lisp string object placed within the
|
|
220 function definition to describe the function for the Emacs help
|
|
221 facilities. @xref{Function Documentation}.
|
6455
|
222
|
|
223 The interactive declaration is a list of the form @code{(interactive
|
|
224 @var{code-string})}. This declares how to provide arguments if the
|
|
225 function is used interactively. Functions with this declaration are called
|
|
226 @dfn{commands}; they can be called using @kbd{M-x} or bound to a key.
|
|
227 Functions not intended to be called in this way should not have interactive
|
|
228 declarations. @xref{Defining Commands}, for how to write an interactive
|
|
229 declaration.
|
|
230
|
|
231 @cindex body of function
|
|
232 The rest of the elements are the @dfn{body} of the function: the Lisp
|
|
233 code to do the work of the function (or, as a Lisp programmer would say,
|
|
234 ``a list of Lisp forms to evaluate''). The value returned by the
|
|
235 function is the value returned by the last element of the body.
|
|
236
|
|
237 @node Simple Lambda
|
|
238 @subsection A Simple Lambda-Expression Example
|
|
239
|
|
240 Consider for example the following function:
|
|
241
|
|
242 @example
|
|
243 (lambda (a b c) (+ a b c))
|
|
244 @end example
|
|
245
|
|
246 @noindent
|
|
247 We can call this function by writing it as the @sc{car} of an
|
|
248 expression, like this:
|
|
249
|
|
250 @example
|
|
251 @group
|
|
252 ((lambda (a b c) (+ a b c))
|
|
253 1 2 3)
|
|
254 @end group
|
|
255 @end example
|
|
256
|
|
257 @noindent
|
|
258 This call evaluates the body of the lambda expression with the variable
|
|
259 @code{a} bound to 1, @code{b} bound to 2, and @code{c} bound to 3.
|
|
260 Evaluation of the body adds these three numbers, producing the result 6;
|
|
261 therefore, this call to the function returns the value 6.
|
|
262
|
|
263 Note that the arguments can be the results of other function calls, as in
|
|
264 this example:
|
|
265
|
|
266 @example
|
|
267 @group
|
|
268 ((lambda (a b c) (+ a b c))
|
|
269 1 (* 2 3) (- 5 4))
|
|
270 @end group
|
|
271 @end example
|
|
272
|
|
273 @noindent
|
|
274 This evaluates the arguments @code{1}, @code{(* 2 3)}, and @code{(- 5
|
7193
|
275 4)} from left to right. Then it applies the lambda expression to the
|
|
276 argument values 1, 6 and 1 to produce the value 8.
|
6455
|
277
|
|
278 It is not often useful to write a lambda expression as the @sc{car} of
|
|
279 a form in this way. You can get the same result, of making local
|
|
280 variables and giving them values, using the special form @code{let}
|
|
281 (@pxref{Local Variables}). And @code{let} is clearer and easier to use.
|
|
282 In practice, lambda expressions are either stored as the function
|
|
283 definitions of symbols, to produce named functions, or passed as
|
|
284 arguments to other functions (@pxref{Anonymous Functions}).
|
|
285
|
|
286 However, calls to explicit lambda expressions were very useful in the
|
|
287 old days of Lisp, before the special form @code{let} was invented. At
|
|
288 that time, they were the only way to bind and initialize local
|
|
289 variables.
|
|
290
|
|
291 @node Argument List
|
21007
|
292 @subsection Other Features of Argument Lists
|
6455
|
293 @kindex wrong-number-of-arguments
|
|
294 @cindex argument binding
|
|
295 @cindex binding arguments
|
|
296
|
|
297 Our simple sample function, @code{(lambda (a b c) (+ a b c))},
|
|
298 specifies three argument variables, so it must be called with three
|
|
299 arguments: if you try to call it with only two arguments or four
|
|
300 arguments, you get a @code{wrong-number-of-arguments} error.
|
|
301
|
|
302 It is often convenient to write a function that allows certain
|
|
303 arguments to be omitted. For example, the function @code{substring}
|
|
304 accepts three arguments---a string, the start index and the end
|
|
305 index---but the third argument defaults to the @var{length} of the
|
|
306 string if you omit it. It is also convenient for certain functions to
|
7193
|
307 accept an indefinite number of arguments, as the functions @code{list}
|
6455
|
308 and @code{+} do.
|
|
309
|
|
310 @cindex optional arguments
|
|
311 @cindex rest arguments
|
|
312 @kindex &optional
|
|
313 @kindex &rest
|
|
314 To specify optional arguments that may be omitted when a function
|
|
315 is called, simply include the keyword @code{&optional} before the optional
|
|
316 arguments. To specify a list of zero or more extra arguments, include the
|
|
317 keyword @code{&rest} before one final argument.
|
|
318
|
|
319 Thus, the complete syntax for an argument list is as follows:
|
|
320
|
|
321 @example
|
|
322 @group
|
|
323 (@var{required-vars}@dots{}
|
|
324 @r{[}&optional @var{optional-vars}@dots{}@r{]}
|
|
325 @r{[}&rest @var{rest-var}@r{]})
|
|
326 @end group
|
|
327 @end example
|
|
328
|
|
329 @noindent
|
|
330 The square brackets indicate that the @code{&optional} and @code{&rest}
|
|
331 clauses, and the variables that follow them, are optional.
|
|
332
|
|
333 A call to the function requires one actual argument for each of the
|
|
334 @var{required-vars}. There may be actual arguments for zero or more of
|
|
335 the @var{optional-vars}, and there cannot be any actual arguments beyond
|
|
336 that unless the lambda list uses @code{&rest}. In that case, there may
|
|
337 be any number of extra actual arguments.
|
|
338
|
|
339 If actual arguments for the optional and rest variables are omitted,
|
7193
|
340 then they always default to @code{nil}. There is no way for the
|
6455
|
341 function to distinguish between an explicit argument of @code{nil} and
|
7193
|
342 an omitted argument. However, the body of the function is free to
|
|
343 consider @code{nil} an abbreviation for some other meaningful value.
|
|
344 This is what @code{substring} does; @code{nil} as the third argument to
|
|
345 @code{substring} means to use the length of the string supplied.
|
6455
|
346
|
|
347 @cindex CL note---default optional arg
|
|
348 @quotation
|
|
349 @b{Common Lisp note:} Common Lisp allows the function to specify what
|
|
350 default value to use when an optional argument is omitted; Emacs Lisp
|
21007
|
351 always uses @code{nil}. Emacs Lisp does not support ``supplied-p''
|
|
352 variables that tell you whether an argument was explicitly passed.
|
6455
|
353 @end quotation
|
|
354
|
|
355 For example, an argument list that looks like this:
|
|
356
|
|
357 @example
|
|
358 (a b &optional c d &rest e)
|
|
359 @end example
|
|
360
|
|
361 @noindent
|
|
362 binds @code{a} and @code{b} to the first two actual arguments, which are
|
|
363 required. If one or two more arguments are provided, @code{c} and
|
|
364 @code{d} are bound to them respectively; any arguments after the first
|
|
365 four are collected into a list and @code{e} is bound to that list. If
|
|
366 there are only two arguments, @code{c} is @code{nil}; if two or three
|
|
367 arguments, @code{d} is @code{nil}; if four arguments or fewer, @code{e}
|
|
368 is @code{nil}.
|
|
369
|
|
370 There is no way to have required arguments following optional
|
|
371 ones---it would not make sense. To see why this must be so, suppose
|
|
372 that @code{c} in the example were optional and @code{d} were required.
|
39168
|
373 Suppose three actual arguments are given; which variable would the
|
|
374 third argument be for? Would it be used for the @var{c}, or for
|
|
375 @var{d}? One can argue for both possibilities. Similarly, it makes
|
|
376 no sense to have any more arguments (either required or optional)
|
|
377 after a @code{&rest} argument.
|
6455
|
378
|
|
379 Here are some examples of argument lists and proper calls:
|
|
380
|
|
381 @smallexample
|
|
382 ((lambda (n) (1+ n)) ; @r{One required:}
|
|
383 1) ; @r{requires exactly one argument.}
|
|
384 @result{} 2
|
|
385 ((lambda (n &optional n1) ; @r{One required and one optional:}
|
|
386 (if n1 (+ n n1) (1+ n))) ; @r{1 or 2 arguments.}
|
|
387 1 2)
|
|
388 @result{} 3
|
|
389 ((lambda (n &rest ns) ; @r{One required and one rest:}
|
|
390 (+ n (apply '+ ns))) ; @r{1 or more arguments.}
|
|
391 1 2 3 4 5)
|
|
392 @result{} 15
|
|
393 @end smallexample
|
|
394
|
|
395 @node Function Documentation
|
|
396 @subsection Documentation Strings of Functions
|
|
397 @cindex documentation of function
|
|
398
|
|
399 A lambda expression may optionally have a @dfn{documentation string} just
|
|
400 after the lambda list. This string does not affect execution of the
|
|
401 function; it is a kind of comment, but a systematized comment which
|
|
402 actually appears inside the Lisp world and can be used by the Emacs help
|
|
403 facilities. @xref{Documentation}, for how the @var{documentation-string} is
|
|
404 accessed.
|
|
405
|
12098
|
406 It is a good idea to provide documentation strings for all the
|
21682
|
407 functions in your program, even those that are called only from within
|
12098
|
408 your program. Documentation strings are like comments, except that they
|
|
409 are easier to access.
|
6455
|
410
|
|
411 The first line of the documentation string should stand on its own,
|
|
412 because @code{apropos} displays just this first line. It should consist
|
|
413 of one or two complete sentences that summarize the function's purpose.
|
|
414
|
60038
|
415 The start of the documentation string is usually indented in the
|
|
416 source file, but since these spaces come before the starting
|
|
417 double-quote, they are not part of the string. Some people make a
|
|
418 practice of indenting any additional lines of the string so that the
|
|
419 text lines up in the program source. @emph{That is a mistake.} The
|
|
420 indentation of the following lines is inside the string; what looks
|
|
421 nice in the source code will look ugly when displayed by the help
|
|
422 commands.
|
6455
|
423
|
|
424 You may wonder how the documentation string could be optional, since
|
|
425 there are required components of the function that follow it (the body).
|
|
426 Since evaluation of a string returns that string, without any side effects,
|
|
427 it has no effect if it is not the last form in the body. Thus, in
|
|
428 practice, there is no confusion between the first form of the body and the
|
|
429 documentation string; if the only body form is a string then it serves both
|
|
430 as the return value and as the documentation.
|
|
431
|
51998
|
432 The last line of the documentation string can specify calling
|
|
433 conventions different from the actual function arguments. Write
|
|
434 text like this:
|
|
435
|
|
436 @example
|
53483
|
437 \(fn @var{arglist})
|
51998
|
438 @end example
|
|
439
|
|
440 @noindent
|
53483
|
441 following a blank line, at the beginning of the line, with no newline
|
60038
|
442 following it inside the documentation string. (The @samp{\} is used
|
|
443 to avoid confusing the Emacs motion commands.) The calling convention
|
|
444 specified in this way appears in help messages in place of the one
|
|
445 derived from the actual arguments of the function.
|
|
446
|
|
447 This feature is particularly useful for macro definitions, since the
|
|
448 arguments written in a macro definition often do not correspond to the
|
|
449 way users think of the parts of the macro call.
|
51998
|
450
|
6455
|
451 @node Function Names
|
|
452 @section Naming a Function
|
|
453 @cindex function definition
|
|
454 @cindex named function
|
|
455 @cindex function name
|
|
456
|
|
457 In most computer languages, every function has a name; the idea of a
|
|
458 function without a name is nonsensical. In Lisp, a function in the
|
|
459 strictest sense has no name. It is simply a list whose first element is
|
21682
|
460 @code{lambda}, a byte-code function object, or a primitive subr-object.
|
6455
|
461
|
|
462 However, a symbol can serve as the name of a function. This happens
|
|
463 when you put the function in the symbol's @dfn{function cell}
|
|
464 (@pxref{Symbol Components}). Then the symbol itself becomes a valid,
|
|
465 callable function, equivalent to the list or subr-object that its
|
|
466 function cell refers to. The contents of the function cell are also
|
|
467 called the symbol's @dfn{function definition}. The procedure of using a
|
|
468 symbol's function definition in place of the symbol is called
|
|
469 @dfn{symbol function indirection}; see @ref{Function Indirection}.
|
|
470
|
|
471 In practice, nearly all functions are given names in this way and
|
|
472 referred to through their names. For example, the symbol @code{car} works
|
|
473 as a function and does what it does because the primitive subr-object
|
|
474 @code{#<subr car>} is stored in its function cell.
|
|
475
|
|
476 We give functions names because it is convenient to refer to them by
|
|
477 their names in Lisp expressions. For primitive subr-objects such as
|
|
478 @code{#<subr car>}, names are the only way you can refer to them: there
|
|
479 is no read syntax for such objects. For functions written in Lisp, the
|
|
480 name is more convenient to use in a call than an explicit lambda
|
|
481 expression. Also, a function with a name can refer to itself---it can
|
|
482 be recursive. Writing the function's name in its own definition is much
|
|
483 more convenient than making the function definition point to itself
|
|
484 (something that is not impossible but that has various disadvantages in
|
|
485 practice).
|
|
486
|
|
487 We often identify functions with the symbols used to name them. For
|
71957
|
488 example, we often speak of ``the function @code{car},'' not
|
6455
|
489 distinguishing between the symbol @code{car} and the primitive
|
60038
|
490 subr-object that is its function definition. For most purposes, the
|
|
491 distinction is not important.
|
6455
|
492
|
|
493 Even so, keep in mind that a function need not have a unique name. While
|
|
494 a given function object @emph{usually} appears in the function cell of only
|
|
495 one symbol, this is just a matter of convenience. It is easy to store
|
|
496 it in several symbols using @code{fset}; then each of the symbols is
|
|
497 equally well a name for the same function.
|
|
498
|
22138
|
499 A symbol used as a function name may also be used as a variable; these
|
|
500 two uses of a symbol are independent and do not conflict. (Some Lisp
|
|
501 dialects, such as Scheme, do not distinguish between a symbol's value
|
|
502 and its function definition; a symbol's value as a variable is also its
|
|
503 function definition.) If you have not given a symbol a function
|
|
504 definition, you cannot use it as a function; whether the symbol has a
|
|
505 value as a variable makes no difference to this.
|
6455
|
506
|
|
507 @node Defining Functions
|
7115
|
508 @section Defining Functions
|
6455
|
509 @cindex defining a function
|
|
510
|
|
511 We usually give a name to a function when it is first created. This
|
|
512 is called @dfn{defining a function}, and it is done with the
|
|
513 @code{defun} special form.
|
|
514
|
|
515 @defspec defun name argument-list body-forms
|
|
516 @code{defun} is the usual way to define new Lisp functions. It
|
|
517 defines the symbol @var{name} as a function that looks like this:
|
|
518
|
|
519 @example
|
|
520 (lambda @var{argument-list} . @var{body-forms})
|
|
521 @end example
|
|
522
|
|
523 @code{defun} stores this lambda expression in the function cell of
|
|
524 @var{name}. It returns the value @var{name}, but usually we ignore this
|
|
525 value.
|
|
526
|
63583
|
527 As described previously, @var{argument-list} is a list of argument
|
|
528 names and may include the keywords @code{&optional} and @code{&rest}
|
|
529 (@pxref{Lambda Expressions}). Also, the first two of the
|
21007
|
530 @var{body-forms} may be a documentation string and an interactive
|
6455
|
531 declaration.
|
|
532
|
|
533 There is no conflict if the same symbol @var{name} is also used as a
|
|
534 variable, since the symbol's value cell is independent of the function
|
|
535 cell. @xref{Symbol Components}.
|
|
536
|
|
537 Here are some examples:
|
|
538
|
|
539 @example
|
|
540 @group
|
|
541 (defun foo () 5)
|
|
542 @result{} foo
|
|
543 @end group
|
|
544 @group
|
|
545 (foo)
|
|
546 @result{} 5
|
|
547 @end group
|
|
548
|
|
549 @group
|
|
550 (defun bar (a &optional b &rest c)
|
|
551 (list a b c))
|
|
552 @result{} bar
|
|
553 @end group
|
|
554 @group
|
|
555 (bar 1 2 3 4 5)
|
|
556 @result{} (1 2 (3 4 5))
|
|
557 @end group
|
|
558 @group
|
|
559 (bar 1)
|
|
560 @result{} (1 nil nil)
|
|
561 @end group
|
|
562 @group
|
|
563 (bar)
|
|
564 @error{} Wrong number of arguments.
|
|
565 @end group
|
|
566
|
|
567 @group
|
|
568 (defun capitalize-backwards ()
|
|
569 "Upcase the last letter of a word."
|
|
570 (interactive)
|
|
571 (backward-word 1)
|
|
572 (forward-word 1)
|
|
573 (backward-char 1)
|
|
574 (capitalize-word 1))
|
|
575 @result{} capitalize-backwards
|
|
576 @end group
|
|
577 @end example
|
|
578
|
|
579 Be careful not to redefine existing functions unintentionally.
|
|
580 @code{defun} redefines even primitive functions such as @code{car}
|
|
581 without any hesitation or notification. Redefining a function already
|
|
582 defined is often done deliberately, and there is no way to distinguish
|
|
583 deliberate redefinition from unintentional redefinition.
|
|
584 @end defspec
|
|
585
|
56215
|
586 @defun defalias name definition &optional docstring
|
53483
|
587 @anchor{Definition of defalias}
|
6455
|
588 This special form defines the symbol @var{name} as a function, with
|
7193
|
589 definition @var{definition} (which can be any valid Lisp function).
|
53483
|
590 It returns @var{definition}.
|
|
591
|
|
592 If @var{docstring} is non-@code{nil}, it becomes the function
|
|
593 documentation of @var{name}. Otherwise, any documentation provided by
|
|
594 @var{definition} is used.
|
12098
|
595
|
|
596 The proper place to use @code{defalias} is where a specific function
|
|
597 name is being defined---especially where that name appears explicitly in
|
|
598 the source file being loaded. This is because @code{defalias} records
|
|
599 which file defined the function, just like @code{defun}
|
|
600 (@pxref{Unloading}).
|
|
601
|
|
602 By contrast, in programs that manipulate function definitions for other
|
|
603 purposes, it is better to use @code{fset}, which does not keep such
|
62096
|
604 records. @xref{Function Cells}.
|
6455
|
605 @end defun
|
|
606
|
51701
|
607 You cannot create a new primitive function with @code{defun} or
|
53483
|
608 @code{defalias}, but you can use them to change the function definition of
|
51701
|
609 any symbol, even one such as @code{car} or @code{x-popup-menu} whose
|
|
610 normal definition is a primitive. However, this is risky: for
|
|
611 instance, it is next to impossible to redefine @code{car} without
|
|
612 breaking Lisp completely. Redefining an obscure function such as
|
|
613 @code{x-popup-menu} is less dangerous, but it still may not work as
|
|
614 you expect. If there are calls to the primitive from C code, they
|
|
615 call the primitive's C definition directly, so changing the symbol's
|
|
616 definition will have no effect on them.
|
|
617
|
12098
|
618 See also @code{defsubst}, which defines a function like @code{defun}
|
|
619 and tells the Lisp compiler to open-code it. @xref{Inline Functions}.
|
|
620
|
6455
|
621 @node Calling Functions
|
|
622 @section Calling Functions
|
|
623 @cindex function invocation
|
|
624 @cindex calling a function
|
|
625
|
|
626 Defining functions is only half the battle. Functions don't do
|
|
627 anything until you @dfn{call} them, i.e., tell them to run. Calling a
|
|
628 function is also known as @dfn{invocation}.
|
|
629
|
7193
|
630 The most common way of invoking a function is by evaluating a list.
|
|
631 For example, evaluating the list @code{(concat "a" "b")} calls the
|
|
632 function @code{concat} with arguments @code{"a"} and @code{"b"}.
|
|
633 @xref{Evaluation}, for a description of evaluation.
|
6455
|
634
|
60038
|
635 When you write a list as an expression in your program, you specify
|
|
636 which function to call, and how many arguments to give it, in the text
|
|
637 of the program. Usually that's just what you want. Occasionally you
|
|
638 need to compute at run time which function to call. To do that, use
|
|
639 the function @code{funcall}. When you also need to determine at run
|
|
640 time how many arguments to pass, use @code{apply}.
|
6455
|
641
|
|
642 @defun funcall function &rest arguments
|
|
643 @code{funcall} calls @var{function} with @var{arguments}, and returns
|
|
644 whatever @var{function} returns.
|
|
645
|
|
646 Since @code{funcall} is a function, all of its arguments, including
|
|
647 @var{function}, are evaluated before @code{funcall} is called. This
|
|
648 means that you can use any expression to obtain the function to be
|
60038
|
649 called. It also means that @code{funcall} does not see the
|
|
650 expressions you write for the @var{arguments}, only their values.
|
|
651 These values are @emph{not} evaluated a second time in the act of
|
|
652 calling @var{function}; the operation of @code{funcall} is like the
|
|
653 normal procedure for calling a function, once its arguments have
|
|
654 already been evaluated.
|
6455
|
655
|
|
656 The argument @var{function} must be either a Lisp function or a
|
|
657 primitive function. Special forms and macros are not allowed, because
|
|
658 they make sense only when given the ``unevaluated'' argument
|
|
659 expressions. @code{funcall} cannot provide these because, as we saw
|
|
660 above, it never knows them in the first place.
|
|
661
|
|
662 @example
|
|
663 @group
|
|
664 (setq f 'list)
|
|
665 @result{} list
|
|
666 @end group
|
|
667 @group
|
|
668 (funcall f 'x 'y 'z)
|
|
669 @result{} (x y z)
|
|
670 @end group
|
|
671 @group
|
|
672 (funcall f 'x 'y '(z))
|
|
673 @result{} (x y (z))
|
|
674 @end group
|
|
675 @group
|
|
676 (funcall 'and t nil)
|
|
677 @error{} Invalid function: #<subr and>
|
|
678 @end group
|
|
679 @end example
|
|
680
|
26192
|
681 Compare these examples with the examples of @code{apply}.
|
6455
|
682 @end defun
|
|
683
|
|
684 @defun apply function &rest arguments
|
|
685 @code{apply} calls @var{function} with @var{arguments}, just like
|
|
686 @code{funcall} but with one difference: the last of @var{arguments} is a
|
21007
|
687 list of objects, which are passed to @var{function} as separate
|
|
688 arguments, rather than a single list. We say that @code{apply}
|
|
689 @dfn{spreads} this list so that each individual element becomes an
|
|
690 argument.
|
6455
|
691
|
|
692 @code{apply} returns the result of calling @var{function}. As with
|
|
693 @code{funcall}, @var{function} must either be a Lisp function or a
|
|
694 primitive function; special forms and macros do not make sense in
|
|
695 @code{apply}.
|
|
696
|
|
697 @example
|
|
698 @group
|
|
699 (setq f 'list)
|
|
700 @result{} list
|
|
701 @end group
|
|
702 @group
|
|
703 (apply f 'x 'y 'z)
|
|
704 @error{} Wrong type argument: listp, z
|
|
705 @end group
|
|
706 @group
|
|
707 (apply '+ 1 2 '(3 4))
|
|
708 @result{} 10
|
|
709 @end group
|
|
710 @group
|
|
711 (apply '+ '(1 2 3 4))
|
|
712 @result{} 10
|
|
713 @end group
|
|
714
|
|
715 @group
|
|
716 (apply 'append '((a b c) nil (x y z) nil))
|
|
717 @result{} (a b c x y z)
|
|
718 @end group
|
|
719 @end example
|
|
720
|
53483
|
721 For an interesting example of using @code{apply}, see @ref{Definition
|
|
722 of mapcar}.
|
6455
|
723 @end defun
|
|
724
|
|
725 @cindex functionals
|
|
726 It is common for Lisp functions to accept functions as arguments or
|
|
727 find them in data structures (especially in hook variables and property
|
|
728 lists) and call them using @code{funcall} or @code{apply}. Functions
|
|
729 that accept function arguments are often called @dfn{functionals}.
|
|
730
|
12098
|
731 Sometimes, when you call a functional, it is useful to supply a no-op
|
|
732 function as the argument. Here are two different kinds of no-op
|
6455
|
733 function:
|
|
734
|
|
735 @defun identity arg
|
|
736 This function returns @var{arg} and has no side effects.
|
|
737 @end defun
|
|
738
|
|
739 @defun ignore &rest args
|
|
740 This function ignores any arguments and returns @code{nil}.
|
|
741 @end defun
|
|
742
|
|
743 @node Mapping Functions
|
|
744 @section Mapping Functions
|
|
745 @cindex mapping functions
|
|
746
|
53483
|
747 A @dfn{mapping function} applies a given function (@emph{not} a
|
|
748 special form or macro) to each element of a list or other collection.
|
|
749 Emacs Lisp has several such functions; @code{mapcar} and
|
|
750 @code{mapconcat}, which scan a list, are described here.
|
|
751 @xref{Definition of mapatoms}, for the function @code{mapatoms} which
|
|
752 maps over the symbols in an obarray. @xref{Definition of maphash},
|
|
753 for the function @code{maphash} which maps over key/value associations
|
|
754 in a hash table.
|
21682
|
755
|
|
756 These mapping functions do not allow char-tables because a char-table
|
|
757 is a sparse array whose nominal range of indices is very large. To map
|
|
758 over a char-table in a way that deals properly with its sparse nature,
|
|
759 use the function @code{map-char-table} (@pxref{Char-Tables}).
|
6455
|
760
|
56215
|
761 @defun mapcar function sequence
|
53483
|
762 @anchor{Definition of mapcar}
|
7193
|
763 @code{mapcar} applies @var{function} to each element of @var{sequence}
|
|
764 in turn, and returns a list of the results.
|
6455
|
765
|
21682
|
766 The argument @var{sequence} can be any kind of sequence except a
|
|
767 char-table; that is, a list, a vector, a bool-vector, or a string. The
|
6455
|
768 result is always a list. The length of the result is the same as the
|
71995
|
769 length of @var{sequence}. For example:
|
6455
|
770
|
|
771 @smallexample
|
|
772 @group
|
|
773 (mapcar 'car '((a b) (c d) (e f)))
|
|
774 @result{} (a c e)
|
|
775 (mapcar '1+ [1 2 3])
|
|
776 @result{} (2 3 4)
|
|
777 (mapcar 'char-to-string "abc")
|
|
778 @result{} ("a" "b" "c")
|
|
779 @end group
|
|
780
|
|
781 @group
|
|
782 ;; @r{Call each function in @code{my-hooks}.}
|
|
783 (mapcar 'funcall my-hooks)
|
|
784 @end group
|
|
785
|
|
786 @group
|
21682
|
787 (defun mapcar* (function &rest args)
|
6455
|
788 "Apply FUNCTION to successive cars of all ARGS.
|
|
789 Return the list of results."
|
|
790 ;; @r{If no list is exhausted,}
|
53483
|
791 (if (not (memq nil args))
|
21682
|
792 ;; @r{apply function to @sc{car}s.}
|
49600
|
793 (cons (apply function (mapcar 'car args))
|
|
794 (apply 'mapcar* function
|
6455
|
795 ;; @r{Recurse for rest of elements.}
|
|
796 (mapcar 'cdr args)))))
|
|
797 @end group
|
|
798
|
|
799 @group
|
|
800 (mapcar* 'cons '(a b c) '(1 2 3 4))
|
|
801 @result{} ((a . 1) (b . 2) (c . 3))
|
|
802 @end group
|
|
803 @end smallexample
|
|
804 @end defun
|
|
805
|
28556
|
806 @defun mapc function sequence
|
|
807 @code{mapc} is like @code{mapcar} except that @var{function} is used for
|
|
808 side-effects only---the values it returns are ignored, not collected
|
|
809 into a list. @code{mapc} always returns @var{sequence}.
|
|
810 @end defun
|
|
811
|
6455
|
812 @defun mapconcat function sequence separator
|
|
813 @code{mapconcat} applies @var{function} to each element of
|
|
814 @var{sequence}: the results, which must be strings, are concatenated.
|
|
815 Between each pair of result strings, @code{mapconcat} inserts the string
|
|
816 @var{separator}. Usually @var{separator} contains a space or comma or
|
|
817 other suitable punctuation.
|
|
818
|
|
819 The argument @var{function} must be a function that can take one
|
21682
|
820 argument and return a string. The argument @var{sequence} can be any
|
|
821 kind of sequence except a char-table; that is, a list, a vector, a
|
|
822 bool-vector, or a string.
|
49600
|
823
|
6455
|
824 @smallexample
|
|
825 @group
|
|
826 (mapconcat 'symbol-name
|
|
827 '(The cat in the hat)
|
|
828 " ")
|
|
829 @result{} "The cat in the hat"
|
|
830 @end group
|
|
831
|
|
832 @group
|
|
833 (mapconcat (function (lambda (x) (format "%c" (1+ x))))
|
|
834 "HAL-8000"
|
|
835 "")
|
|
836 @result{} "IBM.9111"
|
|
837 @end group
|
|
838 @end smallexample
|
|
839 @end defun
|
|
840
|
|
841 @node Anonymous Functions
|
|
842 @section Anonymous Functions
|
|
843 @cindex anonymous function
|
|
844
|
|
845 In Lisp, a function is a list that starts with @code{lambda}, a
|
|
846 byte-code function compiled from such a list, or alternatively a
|
71957
|
847 primitive subr-object; names are ``extra.'' Although usually functions
|
6455
|
848 are defined with @code{defun} and given names at the same time, it is
|
|
849 occasionally more concise to use an explicit lambda expression---an
|
|
850 anonymous function. Such a list is valid wherever a function name is.
|
|
851
|
|
852 Any method of creating such a list makes a valid function. Even this:
|
|
853
|
|
854 @smallexample
|
|
855 @group
|
42687
|
856 (setq silly (append '(lambda (x)) (list (list '+ (* 3 4) 'x))))
|
6455
|
857 @result{} (lambda (x) (+ 12 x))
|
|
858 @end group
|
|
859 @end smallexample
|
|
860
|
|
861 @noindent
|
|
862 This computes a list that looks like @code{(lambda (x) (+ 12 x))} and
|
|
863 makes it the value (@emph{not} the function definition!) of
|
|
864 @code{silly}.
|
|
865
|
|
866 Here is how we might call this function:
|
|
867
|
|
868 @example
|
|
869 @group
|
|
870 (funcall silly 1)
|
|
871 @result{} 13
|
|
872 @end group
|
|
873 @end example
|
|
874
|
|
875 @noindent
|
|
876 (It does @emph{not} work to write @code{(silly 1)}, because this function
|
|
877 is not the @emph{function definition} of @code{silly}. We have not given
|
|
878 @code{silly} any function definition, just a value as a variable.)
|
|
879
|
|
880 Most of the time, anonymous functions are constants that appear in
|
21007
|
881 your program. For example, you might want to pass one as an argument to
|
|
882 the function @code{mapcar}, which applies any given function to each
|
|
883 element of a list.
|
|
884
|
49600
|
885 Here we define a function @code{change-property} which
|
21007
|
886 uses a function as its third argument:
|
6455
|
887
|
|
888 @example
|
|
889 @group
|
21007
|
890 (defun change-property (symbol prop function)
|
|
891 (let ((value (get symbol prop)))
|
|
892 (put symbol prop (funcall function value))))
|
6455
|
893 @end group
|
21007
|
894 @end example
|
|
895
|
|
896 @noindent
|
|
897 Here we define a function that uses @code{change-property},
|
21682
|
898 passing it a function to double a number:
|
21007
|
899
|
|
900 @example
|
6455
|
901 @group
|
21007
|
902 (defun double-property (symbol prop)
|
42647
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
903 (change-property symbol prop '(lambda (x) (* 2 x))))
|
6455
|
904 @end group
|
|
905 @end example
|
|
906
|
|
907 @noindent
|
|
908 In such cases, we usually use the special form @code{function} instead
|
21007
|
909 of simple quotation to quote the anonymous function, like this:
|
|
910
|
|
911 @example
|
|
912 @group
|
|
913 (defun double-property (symbol prop)
|
22138
|
914 (change-property symbol prop
|
|
915 (function (lambda (x) (* 2 x)))))
|
21007
|
916 @end group
|
|
917 @end example
|
|
918
|
|
919 Using @code{function} instead of @code{quote} makes a difference if you
|
|
920 compile the function @code{double-property}. For example, if you
|
|
921 compile the second definition of @code{double-property}, the anonymous
|
|
922 function is compiled as well. By contrast, if you compile the first
|
|
923 definition which uses ordinary @code{quote}, the argument passed to
|
|
924 @code{change-property} is the precise list shown:
|
|
925
|
|
926 @example
|
|
927 (lambda (x) (* x 2))
|
|
928 @end example
|
|
929
|
|
930 @noindent
|
|
931 The Lisp compiler cannot assume this list is a function, even though it
|
|
932 looks like one, since it does not know what @code{change-property} will
|
22138
|
933 do with the list. Perhaps it will check whether the @sc{car} of the third
|
21007
|
934 element is the symbol @code{*}! Using @code{function} tells the
|
|
935 compiler it is safe to go ahead and compile the constant function.
|
|
936
|
42647
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
937 Nowadays it is possible to omit @code{function} entirely, like this:
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
938
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
939 @example
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
940 @group
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
941 (defun double-property (symbol prop)
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
942 (change-property symbol prop (lambda (x) (* 2 x))))
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
943 @end group
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
944 @end example
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
945
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
946 @noindent
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
947 This is because @code{lambda} itself implies @code{function}.
|
3e0b4b8d4f7e
Fix the double-property examples. Include one with a bare lambda.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
948
|
21007
|
949 We sometimes write @code{function} instead of @code{quote} when
|
|
950 quoting the name of a function, but this usage is just a sort of
|
|
951 comment:
|
|
952
|
|
953 @example
|
|
954 (function @var{symbol}) @equiv{} (quote @var{symbol}) @equiv{} '@var{symbol}
|
|
955 @end example
|
6455
|
956
|
25751
|
957 @cindex @samp{#'} syntax
|
22138
|
958 The read syntax @code{#'} is a short-hand for using @code{function}.
|
49600
|
959 For example,
|
22138
|
960
|
|
961 @example
|
|
962 #'(lambda (x) (* x x))
|
|
963 @end example
|
|
964
|
|
965 @noindent
|
|
966 is equivalent to
|
|
967
|
|
968 @example
|
|
969 (function (lambda (x) (* x x)))
|
|
970 @end example
|
|
971
|
6455
|
972 @defspec function function-object
|
|
973 @cindex function quoting
|
|
974 This special form returns @var{function-object} without evaluating it.
|
|
975 In this, it is equivalent to @code{quote}. However, it serves as a
|
|
976 note to the Emacs Lisp compiler that @var{function-object} is intended
|
|
977 to be used only as a function, and therefore can safely be compiled.
|
|
978 Contrast this with @code{quote}, in @ref{Quoting}.
|
|
979 @end defspec
|
|
980
|
53483
|
981 @xref{describe-symbols example}, for a realistic example using
|
|
982 @code{function} and an anonymous function.
|
6455
|
983
|
|
984 @node Function Cells
|
|
985 @section Accessing Function Cell Contents
|
|
986
|
|
987 The @dfn{function definition} of a symbol is the object stored in the
|
|
988 function cell of the symbol. The functions described here access, test,
|
|
989 and set the function cell of symbols.
|
|
990
|
53483
|
991 See also the function @code{indirect-function}. @xref{Definition of
|
|
992 indirect-function}.
|
7193
|
993
|
6455
|
994 @defun symbol-function symbol
|
|
995 @kindex void-function
|
|
996 This returns the object in the function cell of @var{symbol}. If the
|
|
997 symbol's function cell is void, a @code{void-function} error is
|
|
998 signaled.
|
|
999
|
|
1000 This function does not check that the returned object is a legitimate
|
|
1001 function.
|
|
1002
|
|
1003 @example
|
|
1004 @group
|
|
1005 (defun bar (n) (+ n 2))
|
|
1006 @result{} bar
|
|
1007 @end group
|
|
1008 @group
|
|
1009 (symbol-function 'bar)
|
|
1010 @result{} (lambda (n) (+ n 2))
|
|
1011 @end group
|
|
1012 @group
|
|
1013 (fset 'baz 'bar)
|
|
1014 @result{} bar
|
|
1015 @end group
|
|
1016 @group
|
|
1017 (symbol-function 'baz)
|
|
1018 @result{} bar
|
|
1019 @end group
|
|
1020 @end example
|
|
1021 @end defun
|
|
1022
|
|
1023 @cindex void function cell
|
|
1024 If you have never given a symbol any function definition, we say that
|
|
1025 that symbol's function cell is @dfn{void}. In other words, the function
|
|
1026 cell does not have any Lisp object in it. If you try to call such a symbol
|
|
1027 as a function, it signals a @code{void-function} error.
|
|
1028
|
|
1029 Note that void is not the same as @code{nil} or the symbol
|
|
1030 @code{void}. The symbols @code{nil} and @code{void} are Lisp objects,
|
|
1031 and can be stored into a function cell just as any other object can be
|
|
1032 (and they can be valid functions if you define them in turn with
|
7193
|
1033 @code{defun}). A void function cell contains no object whatsoever.
|
6455
|
1034
|
|
1035 You can test the voidness of a symbol's function definition with
|
|
1036 @code{fboundp}. After you have given a symbol a function definition, you
|
|
1037 can make it void once more using @code{fmakunbound}.
|
|
1038
|
|
1039 @defun fboundp symbol
|
|
1040 This function returns @code{t} if the symbol has an object in its
|
|
1041 function cell, @code{nil} otherwise. It does not check that the object
|
|
1042 is a legitimate function.
|
|
1043 @end defun
|
|
1044
|
|
1045 @defun fmakunbound symbol
|
|
1046 This function makes @var{symbol}'s function cell void, so that a
|
53483
|
1047 subsequent attempt to access this cell will cause a
|
|
1048 @code{void-function} error. It returns @var{symbol}. (See also
|
|
1049 @code{makunbound}, in @ref{Void Variables}.)
|
6455
|
1050
|
|
1051 @example
|
|
1052 @group
|
|
1053 (defun foo (x) x)
|
21007
|
1054 @result{} foo
|
6455
|
1055 @end group
|
|
1056 @group
|
7193
|
1057 (foo 1)
|
|
1058 @result{}1
|
|
1059 @end group
|
|
1060 @group
|
6455
|
1061 (fmakunbound 'foo)
|
21007
|
1062 @result{} foo
|
6455
|
1063 @end group
|
|
1064 @group
|
|
1065 (foo 1)
|
|
1066 @error{} Symbol's function definition is void: foo
|
|
1067 @end group
|
|
1068 @end example
|
|
1069 @end defun
|
|
1070
|
16755
|
1071 @defun fset symbol definition
|
21007
|
1072 This function stores @var{definition} in the function cell of
|
|
1073 @var{symbol}. The result is @var{definition}. Normally
|
|
1074 @var{definition} should be a function or the name of a function, but
|
|
1075 this is not checked. The argument @var{symbol} is an ordinary evaluated
|
|
1076 argument.
|
6455
|
1077
|
|
1078 There are three normal uses of this function:
|
|
1079
|
|
1080 @itemize @bullet
|
|
1081 @item
|
21682
|
1082 Copying one symbol's function definition to another---in other words,
|
|
1083 making an alternate name for a function. (If you think of this as the
|
|
1084 definition of the new name, you should use @code{defalias} instead of
|
53483
|
1085 @code{fset}; see @ref{Definition of defalias}.)
|
6455
|
1086
|
|
1087 @item
|
|
1088 Giving a symbol a function definition that is not a list and therefore
|
7193
|
1089 cannot be made with @code{defun}. For example, you can use @code{fset}
|
|
1090 to give a symbol @code{s1} a function definition which is another symbol
|
|
1091 @code{s2}; then @code{s1} serves as an alias for whatever definition
|
21682
|
1092 @code{s2} presently has. (Once again use @code{defalias} instead of
|
|
1093 @code{fset} if you think of this as the definition of @code{s1}.)
|
6455
|
1094
|
|
1095 @item
|
|
1096 In constructs for defining or altering functions. If @code{defun}
|
|
1097 were not a primitive, it could be written in Lisp (as a macro) using
|
|
1098 @code{fset}.
|
|
1099 @end itemize
|
|
1100
|
21682
|
1101 Here are examples of these uses:
|
6455
|
1102
|
|
1103 @example
|
|
1104 @group
|
21682
|
1105 ;; @r{Save @code{foo}'s definition in @code{old-foo}.}
|
|
1106 (fset 'old-foo (symbol-function 'foo))
|
6455
|
1107 @end group
|
|
1108
|
|
1109 @group
|
|
1110 ;; @r{Make the symbol @code{car} the function definition of @code{xfirst}.}
|
21682
|
1111 ;; @r{(Most likely, @code{defalias} would be better than @code{fset} here.)}
|
6455
|
1112 (fset 'xfirst 'car)
|
|
1113 @result{} car
|
|
1114 @end group
|
|
1115 @group
|
|
1116 (xfirst '(1 2 3))
|
|
1117 @result{} 1
|
|
1118 @end group
|
|
1119 @group
|
|
1120 (symbol-function 'xfirst)
|
|
1121 @result{} car
|
|
1122 @end group
|
|
1123 @group
|
|
1124 (symbol-function (symbol-function 'xfirst))
|
|
1125 @result{} #<subr car>
|
|
1126 @end group
|
|
1127
|
|
1128 @group
|
|
1129 ;; @r{Define a named keyboard macro.}
|
|
1130 (fset 'kill-two-lines "\^u2\^k")
|
|
1131 @result{} "\^u2\^k"
|
|
1132 @end group
|
21682
|
1133
|
|
1134 @group
|
|
1135 ;; @r{Here is a function that alters other functions.}
|
|
1136 (defun copy-function-definition (new old)
|
|
1137 "Define NEW with the same function definition as OLD."
|
|
1138 (fset new (symbol-function old)))
|
|
1139 @end group
|
6455
|
1140 @end example
|
|
1141 @end defun
|
|
1142
|
60038
|
1143 @code{fset} is sometimes used to save the old definition of a
|
|
1144 function before redefining it. That permits the new definition to
|
|
1145 invoke the old definition. But it is unmodular and unclean for a Lisp
|
|
1146 file to redefine a function defined elsewhere. If you want to modify
|
|
1147 a function defined by another package, it is cleaner to use
|
|
1148 @code{defadvice} (@pxref{Advising Functions}).
|
12098
|
1149
|
62096
|
1150 @node Obsolete Functions
|
|
1151 @section Declaring Functions Obsolete
|
|
1152
|
|
1153 You can use @code{make-obsolete} to declare a function obsolete. This
|
|
1154 indicates that the function may be removed at some stage in the future.
|
|
1155
|
63477
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1156 @defun make-obsolete obsolete-name current-name &optional when
|
62096
|
1157 This function makes the byte compiler warn that the function
|
63477
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1158 @var{obsolete-name} is obsolete. If @var{current-name} is a symbol, the
|
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1159 warning message says to use @var{current-name} instead of
|
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1160 @var{obsolete-name}. @var{current-name} does not need to be an alias for
|
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1161 @var{obsolete-name}; it can be a different function with similar
|
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1162 functionality. If @var{current-name} is a string, it is the warning
|
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1163 message.
|
62096
|
1164
|
|
1165 If provided, @var{when} should be a string indicating when the function
|
|
1166 was first made obsolete---for example, a date or a release number.
|
|
1167 @end defun
|
|
1168
|
|
1169 You can define a function as an alias and declare it obsolete at the
|
|
1170 same time using the macro @code{define-obsolete-function-alias}.
|
|
1171
|
63477
f0e4b6c7de96
(Obsolete Functions): Update argument names of `make-obsolete' and
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1172 @defmac define-obsolete-function-alias obsolete-name current-name &optional when docstring
|
63583
|
1173 This macro marks the function @var{obsolete-name} obsolete and also
|
|
1174 defines it as an alias for the function @var{current-name}. It is
|
|
1175 equivalent to the following:
|
62096
|
1176
|
|
1177 @example
|
63583
|
1178 (defalias @var{obsolete-name} @var{current-name} @var{docstring})
|
|
1179 (make-obsolete @var{obsolete-name} @var{current-name} @var{when})
|
62096
|
1180 @end example
|
|
1181 @end defmac
|
|
1182
|
6455
|
1183 @node Inline Functions
|
|
1184 @section Inline Functions
|
|
1185 @cindex inline functions
|
|
1186
|
|
1187 @findex defsubst
|
|
1188 You can define an @dfn{inline function} by using @code{defsubst} instead
|
|
1189 of @code{defun}. An inline function works just like an ordinary
|
|
1190 function except for one thing: when you compile a call to the function,
|
|
1191 the function's definition is open-coded into the caller.
|
|
1192
|
|
1193 Making a function inline makes explicit calls run faster. But it also
|
|
1194 has disadvantages. For one thing, it reduces flexibility; if you change
|
|
1195 the definition of the function, calls already inlined still use the old
|
|
1196 definition until you recompile them. Since the flexibility of
|
|
1197 redefining functions is an important feature of Emacs, you should not
|
|
1198 make a function inline unless its speed is really crucial.
|
|
1199
|
|
1200 Another disadvantage is that making a large function inline can increase
|
|
1201 the size of compiled code both in files and in memory. Since the speed
|
|
1202 advantage of inline functions is greatest for small functions, you
|
|
1203 generally should not make large functions inline.
|
|
1204
|
|
1205 It's possible to define a macro to expand into the same code that an
|
21682
|
1206 inline function would execute. (@xref{Macros}.) But the macro would be
|
|
1207 limited to direct use in expressions---a macro cannot be called with
|
6455
|
1208 @code{apply}, @code{mapcar} and so on. Also, it takes some work to
|
21682
|
1209 convert an ordinary function into a macro. To convert it into an inline
|
|
1210 function is very easy; simply replace @code{defun} with @code{defsubst}.
|
|
1211 Since each argument of an inline function is evaluated exactly once, you
|
|
1212 needn't worry about how many times the body uses the arguments, as you
|
|
1213 do for macros. (@xref{Argument Evaluation}.)
|
6455
|
1214
|
7193
|
1215 Inline functions can be used and open-coded later on in the same file,
|
6455
|
1216 following the definition, just like macros.
|
|
1217
|
51701
|
1218 @node Function Safety
|
62096
|
1219 @section Determining whether a Function is Safe to Call
|
47667
|
1220 @cindex function safety
|
|
1221 @cindex safety of functions
|
|
1222
|
52924
|
1223 Some major modes such as SES call functions that are stored in user
|
|
1224 files. (@inforef{Top, ,ses}, for more information on SES.) User
|
|
1225 files sometimes have poor pedigrees---you can get a spreadsheet from
|
|
1226 someone you've just met, or you can get one through email from someone
|
|
1227 you've never met. So it is risky to call a function whose source code
|
|
1228 is stored in a user file until you have determined that it is safe.
|
47667
|
1229
|
|
1230 @defun unsafep form &optional unsafep-vars
|
52759
|
1231 Returns @code{nil} if @var{form} is a @dfn{safe} Lisp expression, or
|
51701
|
1232 returns a list that describes why it might be unsafe. The argument
|
47667
|
1233 @var{unsafep-vars} is a list of symbols known to have temporary
|
|
1234 bindings at this point; it is mainly used for internal recursive
|
|
1235 calls. The current buffer is an implicit argument, which provides a
|
|
1236 list of buffer-local bindings.
|
|
1237 @end defun
|
|
1238
|
|
1239 Being quick and simple, @code{unsafep} does a very light analysis and
|
|
1240 rejects many Lisp expressions that are actually safe. There are no
|
51701
|
1241 known cases where @code{unsafep} returns @code{nil} for an unsafe
|
|
1242 expression. However, a ``safe'' Lisp expression can return a string
|
|
1243 with a @code{display} property, containing an associated Lisp
|
|
1244 expression to be executed after the string is inserted into a buffer.
|
|
1245 This associated expression can be a virus. In order to be safe, you
|
|
1246 must delete properties from all strings calculated by user code before
|
47667
|
1247 inserting them into buffers.
|
|
1248
|
51701
|
1249 @ignore
|
47667
|
1250 What is a safe Lisp expression? Basically, it's an expression that
|
|
1251 calls only built-in functions with no side effects (or only innocuous
|
|
1252 ones). Innocuous side effects include displaying messages and
|
|
1253 altering non-risky buffer-local variables (but not global variables).
|
|
1254
|
|
1255 @table @dfn
|
|
1256 @item Safe expression
|
|
1257 @itemize
|
|
1258 @item
|
|
1259 An atom or quoted thing.
|
|
1260 @item
|
|
1261 A call to a safe function (see below), if all its arguments are
|
|
1262 safe expressions.
|
|
1263 @item
|
51701
|
1264 One of the special forms @code{and}, @code{catch}, @code{cond},
|
|
1265 @code{if}, @code{or}, @code{prog1}, @code{prog2}, @code{progn},
|
|
1266 @code{while}, and @code{unwind-protect}], if all its arguments are
|
|
1267 safe.
|
47667
|
1268 @item
|
51701
|
1269 A form that creates temporary bindings (@code{condition-case},
|
|
1270 @code{dolist}, @code{dotimes}, @code{lambda}, @code{let}, or
|
|
1271 @code{let*}), if all args are safe and the symbols to be bound are not
|
|
1272 explicitly risky (see @pxref{File Local Variables}).
|
47667
|
1273 @item
|
51701
|
1274 An assignment using @code{add-to-list}, @code{setq}, @code{push}, or
|
|
1275 @code{pop}, if all args are safe and the symbols to be assigned are
|
|
1276 not explicitly risky and they already have temporary or buffer-local
|
|
1277 bindings.
|
47667
|
1278 @item
|
|
1279 One of [apply, mapc, mapcar, mapconcat] if the first argument is a
|
|
1280 safe explicit lambda and the other args are safe expressions.
|
|
1281 @end itemize
|
|
1282
|
|
1283 @item Safe function
|
|
1284 @itemize
|
|
1285 @item
|
|
1286 A lambda containing safe expressions.
|
|
1287 @item
|
|
1288 A symbol on the list @code{safe-functions}, so the user says it's safe.
|
|
1289 @item
|
51701
|
1290 A symbol with a non-@code{nil} @code{side-effect-free} property.
|
47667
|
1291 @item
|
51701
|
1292 A symbol with a non-@code{nil} @code{safe-function} property. Value t
|
47667
|
1293 indicates a function that is safe but has innocuous side effects.
|
|
1294 Other values will someday indicate functions with classes of side
|
|
1295 effects that are not always safe.
|
|
1296 @end itemize
|
|
1297
|
|
1298 The @code{side-effect-free} and @code{safe-function} properties are
|
|
1299 provided for built-in functions and for low-level functions and macros
|
|
1300 defined in @file{subr.el}. You can assign these properties for the
|
|
1301 functions you write.
|
|
1302 @end table
|
51701
|
1303 @end ignore
|
6455
|
1304
|
|
1305 @node Related Topics
|
|
1306 @section Other Topics Related to Functions
|
|
1307
|
|
1308 Here is a table of several functions that do things related to
|
|
1309 function calling and function definitions. They are documented
|
|
1310 elsewhere, but we provide cross references here.
|
|
1311
|
|
1312 @table @code
|
|
1313 @item apply
|
|
1314 See @ref{Calling Functions}.
|
|
1315
|
|
1316 @item autoload
|
|
1317 See @ref{Autoload}.
|
|
1318
|
|
1319 @item call-interactively
|
|
1320 See @ref{Interactive Call}.
|
|
1321
|
|
1322 @item commandp
|
|
1323 See @ref{Interactive Call}.
|
|
1324
|
|
1325 @item documentation
|
|
1326 See @ref{Accessing Documentation}.
|
|
1327
|
|
1328 @item eval
|
|
1329 See @ref{Eval}.
|
|
1330
|
|
1331 @item funcall
|
|
1332 See @ref{Calling Functions}.
|
|
1333
|
21682
|
1334 @item function
|
|
1335 See @ref{Anonymous Functions}.
|
|
1336
|
6455
|
1337 @item ignore
|
|
1338 See @ref{Calling Functions}.
|
|
1339
|
|
1340 @item indirect-function
|
54060
|
1341 See @ref{Function Indirection}.
|
6455
|
1342
|
|
1343 @item interactive
|
|
1344 See @ref{Using Interactive}.
|
|
1345
|
|
1346 @item interactive-p
|
|
1347 See @ref{Interactive Call}.
|
|
1348
|
|
1349 @item mapatoms
|
|
1350 See @ref{Creating Symbols}.
|
|
1351
|
|
1352 @item mapcar
|
|
1353 See @ref{Mapping Functions}.
|
|
1354
|
21682
|
1355 @item map-char-table
|
|
1356 See @ref{Char-Tables}.
|
|
1357
|
6455
|
1358 @item mapconcat
|
|
1359 See @ref{Mapping Functions}.
|
|
1360
|
|
1361 @item undefined
|
54060
|
1362 See @ref{Functions for Key Lookup}.
|
6455
|
1363 @end table
|
|
1364
|
52401
|
1365 @ignore
|
|
1366 arch-tag: 39100cdf-8a55-4898-acba-595db619e8e2
|
|
1367 @end ignore
|