Commit | Line | Data |
---|---|---|
b8d4c8d0 GM |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
ba318903 | 3 | @c Copyright (C) 1990-1995, 1998-1999, 2001-2014 Free Software |
ab422c4d | 4 | @c Foundation, Inc. |
b8d4c8d0 | 5 | @c See the file elisp.texi for copying conditions. |
ecc6530d | 6 | @node Functions |
b8d4c8d0 GM |
7 | @chapter Functions |
8 | ||
9 | A Lisp program is composed mainly of Lisp functions. This chapter | |
10 | explains what functions are, how they accept arguments, and how to | |
11 | define them. | |
12 | ||
13 | @menu | |
6c187ef5 SM |
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. | |
20 | * Anonymous Functions:: Lambda expressions are functions with no names. | |
21 | * Function Cells:: Accessing or setting the function definition | |
b8d4c8d0 | 22 | of a symbol. |
6c187ef5 SM |
23 | * Closures:: Functions that enclose a lexical environment. |
24 | * Advising Functions:: Adding to the definition of a function. | |
25 | * Obsolete Functions:: Declaring functions obsolete. | |
26 | * Inline Functions:: Functions that the compiler will expand inline. | |
27 | * Declare Form:: Adding additional information about a function. | |
28 | * Declaring Functions:: Telling the compiler that a function is defined. | |
29 | * Function Safety:: Determining whether a function is safe to call. | |
30 | * Related Topics:: Cross-references to specific Lisp primitives | |
b8d4c8d0 GM |
31 | that have a special bearing on how functions work. |
32 | @end menu | |
33 | ||
34 | @node What Is a Function | |
35 | @section What Is a Function? | |
36 | ||
735cc5ca CY |
37 | @cindex return value |
38 | @cindex value of function | |
39 | @cindex argument | |
40 | In a general sense, a function is a rule for carrying out a | |
41 | computation given input values called @dfn{arguments}. The result of | |
42 | the computation is called the @dfn{value} or @dfn{return value} of the | |
43 | function. The computation can also have side effects, such as lasting | |
44 | changes in the values of variables or the contents of data structures. | |
45 | ||
46 | In most computer languages, every function has a name. But in Lisp, | |
47 | a function in the strictest sense has no name: it is an object which | |
1df7defd | 48 | can @emph{optionally} be associated with a symbol (e.g., @code{car}) |
735cc5ca CY |
49 | that serves as the function name. @xref{Function Names}. When a |
50 | function has been given a name, we usually also refer to that symbol | |
1df7defd | 51 | as a ``function'' (e.g., we refer to ``the function @code{car}''). |
735cc5ca CY |
52 | In this manual, the distinction between a function name and the |
53 | function object itself is usually unimportant, but we will take note | |
54 | wherever it is relevant. | |
55 | ||
56 | Certain function-like objects, called @dfn{special forms} and | |
57 | @dfn{macros}, also accept arguments to carry out computations. | |
58 | However, as explained below, these are not considered functions in | |
59 | Emacs Lisp. | |
60 | ||
61 | Here are important terms for functions and function-like objects: | |
b8d4c8d0 GM |
62 | |
63 | @table @dfn | |
735cc5ca | 64 | @item lambda expression |
1df7defd | 65 | A function (in the strict sense, i.e., a function object) which is |
735cc5ca CY |
66 | written in Lisp. These are described in the following section. |
67 | @ifnottex | |
68 | @xref{Lambda Expressions}. | |
69 | @end ifnottex | |
b8d4c8d0 GM |
70 | |
71 | @item primitive | |
72 | @cindex primitive | |
73 | @cindex subr | |
74 | @cindex built-in function | |
1df7defd | 75 | A function which is callable from Lisp but is actually written in C@. |
735cc5ca CY |
76 | Primitives are also called @dfn{built-in functions}, or @dfn{subrs}. |
77 | Examples include functions like @code{car} and @code{append}. In | |
78 | addition, all special forms (see below) are also considered | |
79 | primitives. | |
80 | ||
81 | Usually, a function is implemented as a primitive because it is a | |
1df7defd | 82 | fundamental part of Lisp (e.g., @code{car}), or because it provides a |
735cc5ca CY |
83 | low-level interface to operating system services, or because it needs |
84 | to run fast. Unlike functions defined in Lisp, primitives can be | |
85 | modified or added only by changing the C sources and recompiling | |
86 | Emacs. See @ref{Writing Emacs Primitives}. | |
b8d4c8d0 GM |
87 | |
88 | @item special form | |
735cc5ca CY |
89 | A primitive that is like a function but does not evaluate all of its |
90 | arguments in the usual way. It may evaluate only some of the | |
91 | arguments, or may evaluate them in an unusual order, or several times. | |
92 | Examples include @code{if}, @code{and}, and @code{while}. | |
93 | @xref{Special Forms}. | |
b8d4c8d0 GM |
94 | |
95 | @item macro | |
96 | @cindex macro | |
735cc5ca CY |
97 | A construct defined in Lisp, which differs from a function in that it |
98 | translates a Lisp expression into another expression which is to be | |
99 | evaluated instead of the original expression. Macros enable Lisp | |
100 | programmers to do the sorts of things that special forms can do. | |
101 | @xref{Macros}. | |
b8d4c8d0 GM |
102 | |
103 | @item command | |
104 | @cindex command | |
735cc5ca CY |
105 | An object which can be invoked via the @code{command-execute} |
106 | primitive, usually due to the user typing in a key sequence | |
107 | @dfn{bound} to that command. @xref{Interactive Call}. A command is | |
108 | usually a function; if the function is written in Lisp, it is made | |
109 | into a command by an @code{interactive} form in the function | |
110 | definition (@pxref{Defining Commands}). Commands that are functions | |
111 | can also be called from Lisp expressions, just like other functions. | |
b8d4c8d0 GM |
112 | |
113 | Keyboard macros (strings and vectors) are commands also, even though | |
735cc5ca CY |
114 | they are not functions. @xref{Keyboard Macros}. We say that a symbol |
115 | is a command if its function cell contains a command (@pxref{Symbol | |
116 | Components}); such a @dfn{named command} can be invoked with | |
117 | @kbd{M-x}. | |
118 | ||
119 | @item closure | |
120 | A function object that is much like a lambda expression, except that | |
121 | it also encloses an ``environment'' of lexical variable bindings. | |
122 | @xref{Closures}. | |
b8d4c8d0 GM |
123 | |
124 | @item byte-code function | |
735cc5ca CY |
125 | A function that has been compiled by the byte compiler. |
126 | @xref{Byte-Code Type}. | |
c7844a27 LMI |
127 | |
128 | @item autoload object | |
129 | @cindex autoload object | |
735cc5ca CY |
130 | A place-holder for a real function. If the autoload object is called, |
131 | Emacs loads the file containing the definition of the real function, | |
132 | and then calls the real function. @xref{Autoload}. | |
b8d4c8d0 GM |
133 | @end table |
134 | ||
735cc5ca CY |
135 | You can use the function @code{functionp} to test if an object is a |
136 | function: | |
137 | ||
b8d4c8d0 GM |
138 | @defun functionp object |
139 | This function returns @code{t} if @var{object} is any kind of | |
1df7defd | 140 | function, i.e., can be passed to @code{funcall}. Note that |
735cc5ca CY |
141 | @code{functionp} returns @code{t} for symbols that are function names, |
142 | and returns @code{nil} for special forms. | |
b8d4c8d0 GM |
143 | @end defun |
144 | ||
735cc5ca CY |
145 | @noindent |
146 | Unlike @code{functionp}, the next three functions do @emph{not} treat | |
147 | a symbol as its function definition. | |
b8d4c8d0 GM |
148 | |
149 | @defun subrp object | |
150 | This function returns @code{t} if @var{object} is a built-in function | |
151 | (i.e., a Lisp primitive). | |
152 | ||
153 | @example | |
154 | @group | |
155 | (subrp 'message) ; @r{@code{message} is a symbol,} | |
156 | @result{} nil ; @r{not a subr object.} | |
157 | @end group | |
158 | @group | |
159 | (subrp (symbol-function 'message)) | |
160 | @result{} t | |
161 | @end group | |
162 | @end example | |
163 | @end defun | |
164 | ||
165 | @defun byte-code-function-p object | |
166 | This function returns @code{t} if @var{object} is a byte-code | |
167 | function. For example: | |
168 | ||
169 | @example | |
170 | @group | |
171 | (byte-code-function-p (symbol-function 'next-line)) | |
172 | @result{} t | |
173 | @end group | |
174 | @end example | |
175 | @end defun | |
176 | ||
177 | @defun subr-arity subr | |
178 | This function provides information about the argument list of a | |
179 | primitive, @var{subr}. The returned value is a pair | |
180 | @code{(@var{min} . @var{max})}. @var{min} is the minimum number of | |
181 | args. @var{max} is the maximum number or the symbol @code{many}, for a | |
182 | function with @code{&rest} arguments, or the symbol @code{unevalled} if | |
183 | @var{subr} is a special form. | |
184 | @end defun | |
185 | ||
186 | @node Lambda Expressions | |
187 | @section Lambda Expressions | |
188 | @cindex lambda expression | |
189 | ||
735cc5ca CY |
190 | A lambda expression is a function object written in Lisp. Here is |
191 | an example: | |
b8d4c8d0 GM |
192 | |
193 | @example | |
735cc5ca CY |
194 | (lambda (x) |
195 | "Return the hyperbolic cosine of X." | |
196 | (* 0.5 (+ (exp x) (exp (- x))))) | |
b8d4c8d0 GM |
197 | @end example |
198 | ||
199 | @noindent | |
a5cf7779 SM |
200 | In Emacs Lisp, such a list is a valid expression which evaluates to |
201 | a function object. | |
735cc5ca CY |
202 | |
203 | A lambda expression, by itself, has no name; it is an @dfn{anonymous | |
204 | function}. Although lambda expressions can be used this way | |
205 | (@pxref{Anonymous Functions}), they are more commonly associated with | |
206 | symbols to make @dfn{named functions} (@pxref{Function Names}). | |
207 | Before going into these details, the following subsections describe | |
208 | the components of a lambda expression and what they do. | |
b8d4c8d0 GM |
209 | |
210 | @menu | |
6c187ef5 SM |
211 | * Lambda Components:: The parts of a lambda expression. |
212 | * Simple Lambda:: A simple example. | |
213 | * Argument List:: Details and special features of argument lists. | |
214 | * Function Documentation:: How to put documentation in a function. | |
b8d4c8d0 GM |
215 | @end menu |
216 | ||
217 | @node Lambda Components | |
218 | @subsection Components of a Lambda Expression | |
219 | ||
735cc5ca | 220 | A lambda expression is a list that looks like this: |
b8d4c8d0 GM |
221 | |
222 | @example | |
223 | (lambda (@var{arg-variables}@dots{}) | |
224 | [@var{documentation-string}] | |
225 | [@var{interactive-declaration}] | |
226 | @var{body-forms}@dots{}) | |
227 | @end example | |
b8d4c8d0 GM |
228 | |
229 | @cindex lambda list | |
230 | The first element of a lambda expression is always the symbol | |
231 | @code{lambda}. This indicates that the list represents a function. The | |
232 | reason functions are defined to start with @code{lambda} is so that | |
233 | other lists, intended for other uses, will not accidentally be valid as | |
234 | functions. | |
235 | ||
236 | The second element is a list of symbols---the argument variable names. | |
237 | This is called the @dfn{lambda list}. When a Lisp function is called, | |
238 | the argument values are matched up against the variables in the lambda | |
239 | list, which are given local bindings with the values provided. | |
240 | @xref{Local Variables}. | |
241 | ||
242 | The documentation string is a Lisp string object placed within the | |
243 | function definition to describe the function for the Emacs help | |
244 | facilities. @xref{Function Documentation}. | |
245 | ||
246 | The interactive declaration is a list of the form @code{(interactive | |
247 | @var{code-string})}. This declares how to provide arguments if the | |
248 | function is used interactively. Functions with this declaration are called | |
249 | @dfn{commands}; they can be called using @kbd{M-x} or bound to a key. | |
250 | Functions not intended to be called in this way should not have interactive | |
251 | declarations. @xref{Defining Commands}, for how to write an interactive | |
252 | declaration. | |
253 | ||
254 | @cindex body of function | |
255 | The rest of the elements are the @dfn{body} of the function: the Lisp | |
256 | code to do the work of the function (or, as a Lisp programmer would say, | |
257 | ``a list of Lisp forms to evaluate''). The value returned by the | |
258 | function is the value returned by the last element of the body. | |
259 | ||
260 | @node Simple Lambda | |
735cc5ca | 261 | @subsection A Simple Lambda Expression Example |
b8d4c8d0 | 262 | |
735cc5ca | 263 | Consider the following example: |
b8d4c8d0 GM |
264 | |
265 | @example | |
266 | (lambda (a b c) (+ a b c)) | |
267 | @end example | |
268 | ||
269 | @noindent | |
88ed9e87 | 270 | We can call this function by passing it to @code{funcall}, like this: |
b8d4c8d0 GM |
271 | |
272 | @example | |
273 | @group | |
88ed9e87 SM |
274 | (funcall (lambda (a b c) (+ a b c)) |
275 | 1 2 3) | |
b8d4c8d0 GM |
276 | @end group |
277 | @end example | |
278 | ||
279 | @noindent | |
280 | This call evaluates the body of the lambda expression with the variable | |
281 | @code{a} bound to 1, @code{b} bound to 2, and @code{c} bound to 3. | |
282 | Evaluation of the body adds these three numbers, producing the result 6; | |
283 | therefore, this call to the function returns the value 6. | |
284 | ||
285 | Note that the arguments can be the results of other function calls, as in | |
286 | this example: | |
287 | ||
288 | @example | |
289 | @group | |
88ed9e87 SM |
290 | (funcall (lambda (a b c) (+ a b c)) |
291 | 1 (* 2 3) (- 5 4)) | |
b8d4c8d0 GM |
292 | @end group |
293 | @end example | |
294 | ||
295 | @noindent | |
296 | This evaluates the arguments @code{1}, @code{(* 2 3)}, and @code{(- 5 | |
297 | 4)} from left to right. Then it applies the lambda expression to the | |
298 | argument values 1, 6 and 1 to produce the value 8. | |
299 | ||
735cc5ca CY |
300 | As these examples show, you can use a form with a lambda expression |
301 | as its @sc{car} to make local variables and give them values. In the | |
302 | old days of Lisp, this technique was the only way to bind and | |
303 | initialize local variables. But nowadays, it is clearer to use the | |
304 | special form @code{let} for this purpose (@pxref{Local Variables}). | |
305 | Lambda expressions are mainly used as anonymous functions for passing | |
306 | as arguments to other functions (@pxref{Anonymous Functions}), or | |
307 | stored as symbol function definitions to produce named functions | |
308 | (@pxref{Function Names}). | |
b8d4c8d0 GM |
309 | |
310 | @node Argument List | |
311 | @subsection Other Features of Argument Lists | |
312 | @kindex wrong-number-of-arguments | |
313 | @cindex argument binding | |
314 | @cindex binding arguments | |
315 | @cindex argument lists, features | |
316 | ||
317 | Our simple sample function, @code{(lambda (a b c) (+ a b c))}, | |
318 | specifies three argument variables, so it must be called with three | |
319 | arguments: if you try to call it with only two arguments or four | |
320 | arguments, you get a @code{wrong-number-of-arguments} error. | |
321 | ||
322 | It is often convenient to write a function that allows certain | |
323 | arguments to be omitted. For example, the function @code{substring} | |
324 | accepts three arguments---a string, the start index and the end | |
325 | index---but the third argument defaults to the @var{length} of the | |
326 | string if you omit it. It is also convenient for certain functions to | |
327 | accept an indefinite number of arguments, as the functions @code{list} | |
328 | and @code{+} do. | |
329 | ||
330 | @cindex optional arguments | |
331 | @cindex rest arguments | |
332 | @kindex &optional | |
333 | @kindex &rest | |
334 | To specify optional arguments that may be omitted when a function | |
335 | is called, simply include the keyword @code{&optional} before the optional | |
336 | arguments. To specify a list of zero or more extra arguments, include the | |
337 | keyword @code{&rest} before one final argument. | |
338 | ||
339 | Thus, the complete syntax for an argument list is as follows: | |
340 | ||
341 | @example | |
342 | @group | |
343 | (@var{required-vars}@dots{} | |
344 | @r{[}&optional @var{optional-vars}@dots{}@r{]} | |
345 | @r{[}&rest @var{rest-var}@r{]}) | |
346 | @end group | |
347 | @end example | |
348 | ||
349 | @noindent | |
350 | The square brackets indicate that the @code{&optional} and @code{&rest} | |
351 | clauses, and the variables that follow them, are optional. | |
352 | ||
353 | A call to the function requires one actual argument for each of the | |
354 | @var{required-vars}. There may be actual arguments for zero or more of | |
355 | the @var{optional-vars}, and there cannot be any actual arguments beyond | |
356 | that unless the lambda list uses @code{&rest}. In that case, there may | |
357 | be any number of extra actual arguments. | |
358 | ||
359 | If actual arguments for the optional and rest variables are omitted, | |
360 | then they always default to @code{nil}. There is no way for the | |
361 | function to distinguish between an explicit argument of @code{nil} and | |
362 | an omitted argument. However, the body of the function is free to | |
363 | consider @code{nil} an abbreviation for some other meaningful value. | |
364 | This is what @code{substring} does; @code{nil} as the third argument to | |
365 | @code{substring} means to use the length of the string supplied. | |
366 | ||
367 | @cindex CL note---default optional arg | |
368 | @quotation | |
369 | @b{Common Lisp note:} Common Lisp allows the function to specify what | |
370 | default value to use when an optional argument is omitted; Emacs Lisp | |
371 | always uses @code{nil}. Emacs Lisp does not support ``supplied-p'' | |
372 | variables that tell you whether an argument was explicitly passed. | |
373 | @end quotation | |
374 | ||
375 | For example, an argument list that looks like this: | |
376 | ||
377 | @example | |
378 | (a b &optional c d &rest e) | |
379 | @end example | |
380 | ||
381 | @noindent | |
382 | binds @code{a} and @code{b} to the first two actual arguments, which are | |
383 | required. If one or two more arguments are provided, @code{c} and | |
384 | @code{d} are bound to them respectively; any arguments after the first | |
385 | four are collected into a list and @code{e} is bound to that list. If | |
386 | there are only two arguments, @code{c} is @code{nil}; if two or three | |
387 | arguments, @code{d} is @code{nil}; if four arguments or fewer, @code{e} | |
388 | is @code{nil}. | |
389 | ||
390 | There is no way to have required arguments following optional | |
391 | ones---it would not make sense. To see why this must be so, suppose | |
392 | that @code{c} in the example were optional and @code{d} were required. | |
393 | Suppose three actual arguments are given; which variable would the | |
394 | third argument be for? Would it be used for the @var{c}, or for | |
395 | @var{d}? One can argue for both possibilities. Similarly, it makes | |
396 | no sense to have any more arguments (either required or optional) | |
397 | after a @code{&rest} argument. | |
398 | ||
399 | Here are some examples of argument lists and proper calls: | |
400 | ||
ddff3351 | 401 | @example |
88ed9e87 SM |
402 | (funcall (lambda (n) (1+ n)) ; @r{One required:} |
403 | 1) ; @r{requires exactly one argument.} | |
b8d4c8d0 | 404 | @result{} 2 |
88ed9e87 SM |
405 | (funcall (lambda (n &optional n1) ; @r{One required and one optional:} |
406 | (if n1 (+ n n1) (1+ n))) ; @r{1 or 2 arguments.} | |
407 | 1 2) | |
b8d4c8d0 | 408 | @result{} 3 |
88ed9e87 SM |
409 | (funcall (lambda (n &rest ns) ; @r{One required and one rest:} |
410 | (+ n (apply '+ ns))) ; @r{1 or more arguments.} | |
411 | 1 2 3 4 5) | |
b8d4c8d0 | 412 | @result{} 15 |
ddff3351 | 413 | @end example |
b8d4c8d0 GM |
414 | |
415 | @node Function Documentation | |
416 | @subsection Documentation Strings of Functions | |
417 | @cindex documentation of function | |
418 | ||
735cc5ca CY |
419 | A lambda expression may optionally have a @dfn{documentation string} |
420 | just after the lambda list. This string does not affect execution of | |
421 | the function; it is a kind of comment, but a systematized comment | |
422 | which actually appears inside the Lisp world and can be used by the | |
423 | Emacs help facilities. @xref{Documentation}, for how the | |
424 | documentation string is accessed. | |
b8d4c8d0 GM |
425 | |
426 | It is a good idea to provide documentation strings for all the | |
427 | functions in your program, even those that are called only from within | |
428 | your program. Documentation strings are like comments, except that they | |
429 | are easier to access. | |
430 | ||
431 | The first line of the documentation string should stand on its own, | |
432 | because @code{apropos} displays just this first line. It should consist | |
433 | of one or two complete sentences that summarize the function's purpose. | |
434 | ||
435 | The start of the documentation string is usually indented in the | |
436 | source file, but since these spaces come before the starting | |
437 | double-quote, they are not part of the string. Some people make a | |
438 | practice of indenting any additional lines of the string so that the | |
439 | text lines up in the program source. @emph{That is a mistake.} The | |
440 | indentation of the following lines is inside the string; what looks | |
441 | nice in the source code will look ugly when displayed by the help | |
442 | commands. | |
443 | ||
444 | You may wonder how the documentation string could be optional, since | |
445 | there are required components of the function that follow it (the body). | |
446 | Since evaluation of a string returns that string, without any side effects, | |
447 | it has no effect if it is not the last form in the body. Thus, in | |
448 | practice, there is no confusion between the first form of the body and the | |
449 | documentation string; if the only body form is a string then it serves both | |
450 | as the return value and as the documentation. | |
451 | ||
452 | The last line of the documentation string can specify calling | |
453 | conventions different from the actual function arguments. Write | |
454 | text like this: | |
455 | ||
456 | @example | |
457 | \(fn @var{arglist}) | |
458 | @end example | |
459 | ||
460 | @noindent | |
461 | following a blank line, at the beginning of the line, with no newline | |
462 | following it inside the documentation string. (The @samp{\} is used | |
463 | to avoid confusing the Emacs motion commands.) The calling convention | |
464 | specified in this way appears in help messages in place of the one | |
465 | derived from the actual arguments of the function. | |
466 | ||
467 | This feature is particularly useful for macro definitions, since the | |
468 | arguments written in a macro definition often do not correspond to the | |
469 | way users think of the parts of the macro call. | |
470 | ||
471 | @node Function Names | |
472 | @section Naming a Function | |
473 | @cindex function definition | |
474 | @cindex named function | |
475 | @cindex function name | |
476 | ||
735cc5ca CY |
477 | A symbol can serve as the name of a function. This happens when the |
478 | symbol's @dfn{function cell} (@pxref{Symbol Components}) contains a | |
1df7defd | 479 | function object (e.g., a lambda expression). Then the symbol itself |
735cc5ca CY |
480 | becomes a valid, callable function, equivalent to the function object |
481 | in its function cell. | |
482 | ||
483 | The contents of the function cell are also called the symbol's | |
484 | @dfn{function definition}. The procedure of using a symbol's function | |
485 | definition in place of the symbol is called @dfn{symbol function | |
486 | indirection}; see @ref{Function Indirection}. If you have not given a | |
487 | symbol a function definition, its function cell is said to be | |
488 | @dfn{void}, and it cannot be used as a function. | |
489 | ||
490 | In practice, nearly all functions have names, and are referred to by | |
491 | their names. You can create a named Lisp function by defining a | |
492 | lambda expression and putting it in a function cell (@pxref{Function | |
493 | Cells}). However, it is more common to use the @code{defun} special | |
494 | form, described in the next section. | |
495 | @ifnottex | |
496 | @xref{Defining Functions}. | |
497 | @end ifnottex | |
b8d4c8d0 GM |
498 | |
499 | We give functions names because it is convenient to refer to them by | |
735cc5ca CY |
500 | their names in Lisp expressions. Also, a named Lisp function can |
501 | easily refer to itself---it can be recursive. Furthermore, primitives | |
502 | can only be referred to textually by their names, since primitive | |
503 | function objects (@pxref{Primitive Function Type}) have no read | |
504 | syntax. | |
505 | ||
506 | A function need not have a unique name. A given function object | |
507 | @emph{usually} appears in the function cell of only one symbol, but | |
508 | this is just a convention. It is easy to store it in several symbols | |
509 | using @code{fset}; then each of the symbols is a valid name for the | |
510 | same function. | |
511 | ||
512 | Note that a symbol used as a function name may also be used as a | |
513 | variable; these two uses of a symbol are independent and do not | |
514 | conflict. (This is not the case in some dialects of Lisp, like | |
515 | Scheme.) | |
b8d4c8d0 GM |
516 | |
517 | @node Defining Functions | |
518 | @section Defining Functions | |
519 | @cindex defining a function | |
520 | ||
521 | We usually give a name to a function when it is first created. This | |
522 | is called @dfn{defining a function}, and it is done with the | |
89b2c8a1 | 523 | @code{defun} macro. |
b8d4c8d0 | 524 | |
d18a0d24 | 525 | @defmac defun name args [doc] [declare] [interactive] body@dots{} |
b8d4c8d0 | 526 | @code{defun} is the usual way to define new Lisp functions. It |
d18a0d24 CY |
527 | defines the symbol @var{name} as a function with argument list |
528 | @var{args} and body forms given by @var{body}. Neither @var{name} nor | |
529 | @var{args} should be quoted. | |
b8d4c8d0 | 530 | |
d18a0d24 CY |
531 | @var{doc}, if present, should be a string specifying the function's |
532 | documentation string (@pxref{Function Documentation}). @var{declare}, | |
533 | if present, should be a @code{declare} form specifying function | |
534 | metadata (@pxref{Declare Form}). @var{interactive}, if present, | |
535 | should be an @code{interactive} form specifying how the function is to | |
536 | be called interactively (@pxref{Interactive Call}). | |
b8d4c8d0 | 537 | |
d18a0d24 | 538 | The return value of @code{defun} is undefined. |
b8d4c8d0 GM |
539 | |
540 | Here are some examples: | |
541 | ||
542 | @example | |
543 | @group | |
544 | (defun foo () 5) | |
b8d4c8d0 GM |
545 | (foo) |
546 | @result{} 5 | |
547 | @end group | |
548 | ||
549 | @group | |
550 | (defun bar (a &optional b &rest c) | |
551 | (list a b c)) | |
b8d4c8d0 GM |
552 | (bar 1 2 3 4 5) |
553 | @result{} (1 2 (3 4 5)) | |
554 | @end group | |
555 | @group | |
556 | (bar 1) | |
557 | @result{} (1 nil nil) | |
558 | @end group | |
559 | @group | |
560 | (bar) | |
561 | @error{} Wrong number of arguments. | |
562 | @end group | |
563 | ||
564 | @group | |
565 | (defun capitalize-backwards () | |
735cc5ca | 566 | "Upcase the last letter of the word at point." |
b8d4c8d0 GM |
567 | (interactive) |
568 | (backward-word 1) | |
569 | (forward-word 1) | |
570 | (backward-char 1) | |
571 | (capitalize-word 1)) | |
b8d4c8d0 GM |
572 | @end group |
573 | @end example | |
574 | ||
575 | Be careful not to redefine existing functions unintentionally. | |
576 | @code{defun} redefines even primitive functions such as @code{car} | |
735cc5ca CY |
577 | without any hesitation or notification. Emacs does not prevent you |
578 | from doing this, because redefining a function is sometimes done | |
579 | deliberately, and there is no way to distinguish deliberate | |
580 | redefinition from unintentional redefinition. | |
48de8b12 | 581 | @end defmac |
b8d4c8d0 GM |
582 | |
583 | @cindex function aliases | |
9097ad86 | 584 | @cindex alias, for functions |
d18a0d24 | 585 | @defun defalias name definition &optional doc |
b8d4c8d0 | 586 | @anchor{Definition of defalias} |
89b2c8a1 | 587 | This function defines the symbol @var{name} as a function, with |
b8d4c8d0 | 588 | definition @var{definition} (which can be any valid Lisp function). |
1053a871 | 589 | Its return value is @emph{undefined}. |
b8d4c8d0 | 590 | |
d18a0d24 CY |
591 | If @var{doc} is non-@code{nil}, it becomes the function documentation |
592 | of @var{name}. Otherwise, any documentation provided by | |
b8d4c8d0 GM |
593 | @var{definition} is used. |
594 | ||
189e7007 GM |
595 | @cindex defalias-fset-function property |
596 | Internally, @code{defalias} normally uses @code{fset} to set the definition. | |
597 | If @var{name} has a @code{defalias-fset-function} property, however, | |
598 | the associated value is used as a function to call in place of @code{fset}. | |
599 | ||
b8d4c8d0 GM |
600 | The proper place to use @code{defalias} is where a specific function |
601 | name is being defined---especially where that name appears explicitly in | |
602 | the source file being loaded. This is because @code{defalias} records | |
603 | which file defined the function, just like @code{defun} | |
604 | (@pxref{Unloading}). | |
605 | ||
606 | By contrast, in programs that manipulate function definitions for other | |
607 | purposes, it is better to use @code{fset}, which does not keep such | |
608 | records. @xref{Function Cells}. | |
609 | @end defun | |
610 | ||
611 | You cannot create a new primitive function with @code{defun} or | |
612 | @code{defalias}, but you can use them to change the function definition of | |
613 | any symbol, even one such as @code{car} or @code{x-popup-menu} whose | |
614 | normal definition is a primitive. However, this is risky: for | |
615 | instance, it is next to impossible to redefine @code{car} without | |
616 | breaking Lisp completely. Redefining an obscure function such as | |
617 | @code{x-popup-menu} is less dangerous, but it still may not work as | |
618 | you expect. If there are calls to the primitive from C code, they | |
619 | call the primitive's C definition directly, so changing the symbol's | |
620 | definition will have no effect on them. | |
621 | ||
622 | See also @code{defsubst}, which defines a function like @code{defun} | |
735cc5ca CY |
623 | and tells the Lisp compiler to perform inline expansion on it. |
624 | @xref{Inline Functions}. | |
b8d4c8d0 GM |
625 | |
626 | @node Calling Functions | |
627 | @section Calling Functions | |
628 | @cindex function invocation | |
629 | @cindex calling a function | |
630 | ||
631 | Defining functions is only half the battle. Functions don't do | |
632 | anything until you @dfn{call} them, i.e., tell them to run. Calling a | |
633 | function is also known as @dfn{invocation}. | |
634 | ||
635 | The most common way of invoking a function is by evaluating a list. | |
636 | For example, evaluating the list @code{(concat "a" "b")} calls the | |
637 | function @code{concat} with arguments @code{"a"} and @code{"b"}. | |
638 | @xref{Evaluation}, for a description of evaluation. | |
639 | ||
640 | When you write a list as an expression in your program, you specify | |
641 | which function to call, and how many arguments to give it, in the text | |
642 | of the program. Usually that's just what you want. Occasionally you | |
643 | need to compute at run time which function to call. To do that, use | |
644 | the function @code{funcall}. When you also need to determine at run | |
645 | time how many arguments to pass, use @code{apply}. | |
646 | ||
647 | @defun funcall function &rest arguments | |
648 | @code{funcall} calls @var{function} with @var{arguments}, and returns | |
649 | whatever @var{function} returns. | |
650 | ||
651 | Since @code{funcall} is a function, all of its arguments, including | |
652 | @var{function}, are evaluated before @code{funcall} is called. This | |
653 | means that you can use any expression to obtain the function to be | |
654 | called. It also means that @code{funcall} does not see the | |
655 | expressions you write for the @var{arguments}, only their values. | |
656 | These values are @emph{not} evaluated a second time in the act of | |
657 | calling @var{function}; the operation of @code{funcall} is like the | |
658 | normal procedure for calling a function, once its arguments have | |
659 | already been evaluated. | |
660 | ||
661 | The argument @var{function} must be either a Lisp function or a | |
662 | primitive function. Special forms and macros are not allowed, because | |
663 | they make sense only when given the ``unevaluated'' argument | |
664 | expressions. @code{funcall} cannot provide these because, as we saw | |
665 | above, it never knows them in the first place. | |
666 | ||
667 | @example | |
668 | @group | |
669 | (setq f 'list) | |
670 | @result{} list | |
671 | @end group | |
672 | @group | |
673 | (funcall f 'x 'y 'z) | |
674 | @result{} (x y z) | |
675 | @end group | |
676 | @group | |
677 | (funcall f 'x 'y '(z)) | |
678 | @result{} (x y (z)) | |
679 | @end group | |
680 | @group | |
681 | (funcall 'and t nil) | |
682 | @error{} Invalid function: #<subr and> | |
683 | @end group | |
684 | @end example | |
685 | ||
686 | Compare these examples with the examples of @code{apply}. | |
687 | @end defun | |
688 | ||
689 | @defun apply function &rest arguments | |
690 | @code{apply} calls @var{function} with @var{arguments}, just like | |
691 | @code{funcall} but with one difference: the last of @var{arguments} is a | |
692 | list of objects, which are passed to @var{function} as separate | |
693 | arguments, rather than a single list. We say that @code{apply} | |
694 | @dfn{spreads} this list so that each individual element becomes an | |
695 | argument. | |
696 | ||
697 | @code{apply} returns the result of calling @var{function}. As with | |
698 | @code{funcall}, @var{function} must either be a Lisp function or a | |
699 | primitive function; special forms and macros do not make sense in | |
700 | @code{apply}. | |
701 | ||
702 | @example | |
703 | @group | |
704 | (setq f 'list) | |
705 | @result{} list | |
706 | @end group | |
707 | @group | |
708 | (apply f 'x 'y 'z) | |
709 | @error{} Wrong type argument: listp, z | |
710 | @end group | |
711 | @group | |
712 | (apply '+ 1 2 '(3 4)) | |
713 | @result{} 10 | |
714 | @end group | |
715 | @group | |
716 | (apply '+ '(1 2 3 4)) | |
717 | @result{} 10 | |
718 | @end group | |
719 | ||
720 | @group | |
721 | (apply 'append '((a b c) nil (x y z) nil)) | |
722 | @result{} (a b c x y z) | |
723 | @end group | |
724 | @end example | |
725 | ||
726 | For an interesting example of using @code{apply}, see @ref{Definition | |
727 | of mapcar}. | |
728 | @end defun | |
729 | ||
80f85d7c EZ |
730 | @cindex partial application of functions |
731 | @cindex currying | |
a18a6d49 | 732 | Sometimes it is useful to fix some of the function's arguments at |
80f85d7c EZ |
733 | certain values, and leave the rest of arguments for when the function |
734 | is actually called. The act of fixing some of the function's | |
735 | arguments is called @dfn{partial application} of the function@footnote{ | |
736 | This is related to, but different from @dfn{currying}, which | |
737 | transforms a function that takes multiple arguments in such a way that | |
738 | it can be called as a chain of functions, each one with a single | |
739 | argument.}. | |
740 | The result is a new function that accepts the rest of | |
741 | arguments and calls the original function with all the arguments | |
a18a6d49 EZ |
742 | combined. |
743 | ||
744 | Here's how to do partial application in Emacs Lisp: | |
80f85d7c EZ |
745 | |
746 | @defun apply-partially func &rest args | |
747 | This function returns a new function which, when called, will call | |
748 | @var{func} with the list of arguments composed from @var{args} and | |
749 | additional arguments specified at the time of the call. If @var{func} | |
750 | accepts @var{n} arguments, then a call to @code{apply-partially} with | |
751 | @w{@code{@var{m} < @var{n}}} arguments will produce a new function of | |
752 | @w{@code{@var{n} - @var{m}}} arguments. | |
753 | ||
834b5485 EZ |
754 | Here's how we could define the built-in function @code{1+}, if it |
755 | didn't exist, using @code{apply-partially} and @code{+}, another | |
756 | built-in function: | |
80f85d7c EZ |
757 | |
758 | @example | |
80f85d7c | 759 | @group |
834b5485 EZ |
760 | (defalias '1+ (apply-partially '+ 1) |
761 | "Increment argument by one.") | |
762 | @end group | |
763 | @group | |
764 | (1+ 10) | |
80f85d7c EZ |
765 | @result{} 11 |
766 | @end group | |
767 | @end example | |
768 | @end defun | |
769 | ||
b8d4c8d0 GM |
770 | @cindex functionals |
771 | It is common for Lisp functions to accept functions as arguments or | |
772 | find them in data structures (especially in hook variables and property | |
773 | lists) and call them using @code{funcall} or @code{apply}. Functions | |
774 | that accept function arguments are often called @dfn{functionals}. | |
775 | ||
776 | Sometimes, when you call a functional, it is useful to supply a no-op | |
777 | function as the argument. Here are two different kinds of no-op | |
778 | function: | |
779 | ||
780 | @defun identity arg | |
781 | This function returns @var{arg} and has no side effects. | |
782 | @end defun | |
783 | ||
784 | @defun ignore &rest args | |
785 | This function ignores any arguments and returns @code{nil}. | |
786 | @end defun | |
787 | ||
735cc5ca CY |
788 | Some functions are user-visible @dfn{commands}, which can be called |
789 | interactively (usually by a key sequence). It is possible to invoke | |
790 | such a command exactly as though it was called interactively, by using | |
791 | the @code{call-interactively} function. @xref{Interactive Call}. | |
413c488d | 792 | |
b8d4c8d0 GM |
793 | @node Mapping Functions |
794 | @section Mapping Functions | |
795 | @cindex mapping functions | |
796 | ||
797 | A @dfn{mapping function} applies a given function (@emph{not} a | |
798 | special form or macro) to each element of a list or other collection. | |
735cc5ca CY |
799 | Emacs Lisp has several such functions; this section describes |
800 | @code{mapcar}, @code{mapc}, and @code{mapconcat}, which map over a | |
801 | list. @xref{Definition of mapatoms}, for the function @code{mapatoms} | |
802 | which maps over the symbols in an obarray. @xref{Definition of | |
803 | maphash}, for the function @code{maphash} which maps over key/value | |
804 | associations in a hash table. | |
b8d4c8d0 GM |
805 | |
806 | These mapping functions do not allow char-tables because a char-table | |
807 | is a sparse array whose nominal range of indices is very large. To map | |
808 | over a char-table in a way that deals properly with its sparse nature, | |
809 | use the function @code{map-char-table} (@pxref{Char-Tables}). | |
810 | ||
811 | @defun mapcar function sequence | |
812 | @anchor{Definition of mapcar} | |
813 | @code{mapcar} applies @var{function} to each element of @var{sequence} | |
814 | in turn, and returns a list of the results. | |
815 | ||
816 | The argument @var{sequence} can be any kind of sequence except a | |
817 | char-table; that is, a list, a vector, a bool-vector, or a string. The | |
818 | result is always a list. The length of the result is the same as the | |
819 | length of @var{sequence}. For example: | |
820 | ||
ddff3351 | 821 | @example |
b8d4c8d0 GM |
822 | @group |
823 | (mapcar 'car '((a b) (c d) (e f))) | |
824 | @result{} (a c e) | |
825 | (mapcar '1+ [1 2 3]) | |
826 | @result{} (2 3 4) | |
3e99b825 | 827 | (mapcar 'string "abc") |
b8d4c8d0 GM |
828 | @result{} ("a" "b" "c") |
829 | @end group | |
830 | ||
831 | @group | |
832 | ;; @r{Call each function in @code{my-hooks}.} | |
833 | (mapcar 'funcall my-hooks) | |
834 | @end group | |
835 | ||
836 | @group | |
837 | (defun mapcar* (function &rest args) | |
838 | "Apply FUNCTION to successive cars of all ARGS. | |
839 | Return the list of results." | |
840 | ;; @r{If no list is exhausted,} | |
841 | (if (not (memq nil args)) | |
842 | ;; @r{apply function to @sc{car}s.} | |
843 | (cons (apply function (mapcar 'car args)) | |
844 | (apply 'mapcar* function | |
845 | ;; @r{Recurse for rest of elements.} | |
846 | (mapcar 'cdr args))))) | |
847 | @end group | |
848 | ||
849 | @group | |
850 | (mapcar* 'cons '(a b c) '(1 2 3 4)) | |
851 | @result{} ((a . 1) (b . 2) (c . 3)) | |
852 | @end group | |
ddff3351 | 853 | @end example |
b8d4c8d0 GM |
854 | @end defun |
855 | ||
856 | @defun mapc function sequence | |
857 | @code{mapc} is like @code{mapcar} except that @var{function} is used for | |
858 | side-effects only---the values it returns are ignored, not collected | |
859 | into a list. @code{mapc} always returns @var{sequence}. | |
860 | @end defun | |
861 | ||
862 | @defun mapconcat function sequence separator | |
863 | @code{mapconcat} applies @var{function} to each element of | |
864 | @var{sequence}: the results, which must be strings, are concatenated. | |
865 | Between each pair of result strings, @code{mapconcat} inserts the string | |
866 | @var{separator}. Usually @var{separator} contains a space or comma or | |
867 | other suitable punctuation. | |
868 | ||
869 | The argument @var{function} must be a function that can take one | |
870 | argument and return a string. The argument @var{sequence} can be any | |
871 | kind of sequence except a char-table; that is, a list, a vector, a | |
872 | bool-vector, or a string. | |
873 | ||
ddff3351 | 874 | @example |
b8d4c8d0 GM |
875 | @group |
876 | (mapconcat 'symbol-name | |
877 | '(The cat in the hat) | |
878 | " ") | |
879 | @result{} "The cat in the hat" | |
880 | @end group | |
881 | ||
882 | @group | |
883 | (mapconcat (function (lambda (x) (format "%c" (1+ x)))) | |
884 | "HAL-8000" | |
885 | "") | |
886 | @result{} "IBM.9111" | |
887 | @end group | |
ddff3351 | 888 | @end example |
b8d4c8d0 GM |
889 | @end defun |
890 | ||
891 | @node Anonymous Functions | |
892 | @section Anonymous Functions | |
893 | @cindex anonymous function | |
894 | ||
735cc5ca CY |
895 | Although functions are usually defined with @code{defun} and given |
896 | names at the same time, it is sometimes convenient to use an explicit | |
897 | lambda expression---an @dfn{anonymous function}. Anonymous functions | |
898 | are valid wherever function names are. They are often assigned as | |
899 | variable values, or as arguments to functions; for instance, you might | |
900 | pass one as the @var{function} argument to @code{mapcar}, which | |
901 | applies that function to each element of a list (@pxref{Mapping | |
902 | Functions}). @xref{describe-symbols example}, for a realistic example | |
903 | of this. | |
904 | ||
905 | When defining a lambda expression that is to be used as an anonymous | |
906 | function, you can in principle use any method to construct the list. | |
907 | But typically you should use the @code{lambda} macro, or the | |
908 | @code{function} special form, or the @code{#'} read syntax: | |
909 | ||
d18a0d24 CY |
910 | @defmac lambda args [doc] [interactive] body@dots{} |
911 | This macro returns an anonymous function with argument list | |
912 | @var{args}, documentation string @var{doc} (if any), interactive spec | |
913 | @var{interactive} (if any), and body forms given by @var{body}. | |
914 | ||
915 | In effect, this macro makes @code{lambda} forms ``self-quoting'': | |
916 | evaluating a form whose @sc{car} is @code{lambda} yields the form | |
917 | itself: | |
b8d4c8d0 | 918 | |
735cc5ca CY |
919 | @example |
920 | (lambda (x) (* x x)) | |
921 | @result{} (lambda (x) (* x x)) | |
922 | @end example | |
b8d4c8d0 | 923 | |
735cc5ca CY |
924 | The @code{lambda} form has one other effect: it tells the Emacs |
925 | evaluator and byte-compiler that its argument is a function, by using | |
926 | @code{function} as a subroutine (see below). | |
927 | @end defmac | |
b8d4c8d0 | 928 | |
735cc5ca CY |
929 | @defspec function function-object |
930 | @cindex function quoting | |
931 | This special form returns @var{function-object} without evaluating it. | |
932 | In this, it is similar to @code{quote} (@pxref{Quoting}). But unlike | |
933 | @code{quote}, it also serves as a note to the Emacs evaluator and | |
934 | byte-compiler that @var{function-object} is intended to be used as a | |
935 | function. Assuming @var{function-object} is a valid lambda | |
936 | expression, this has two effects: | |
b8d4c8d0 | 937 | |
735cc5ca CY |
938 | @itemize |
939 | @item | |
940 | When the code is byte-compiled, @var{function-object} is compiled into | |
941 | a byte-code function object (@pxref{Byte Compilation}). | |
b8d4c8d0 | 942 | |
735cc5ca CY |
943 | @item |
944 | When lexical binding is enabled, @var{function-object} is converted | |
945 | into a closure. @xref{Closures}. | |
946 | @end itemize | |
947 | @end defspec | |
b8d4c8d0 | 948 | |
735cc5ca CY |
949 | @cindex @samp{#'} syntax |
950 | The read syntax @code{#'} is a short-hand for using @code{function}. | |
951 | The following forms are all equivalent: | |
b8d4c8d0 | 952 | |
735cc5ca CY |
953 | @example |
954 | (lambda (x) (* x x)) | |
955 | (function (lambda (x) (* x x))) | |
956 | #'(lambda (x) (* x x)) | |
957 | @end example | |
b8d4c8d0 | 958 | |
5d6ab672 CY |
959 | In the following example, we define a @code{change-property} |
960 | function that takes a function as its third argument, followed by a | |
961 | @code{double-property} function that makes use of | |
962 | @code{change-property} by passing it an anonymous function: | |
b8d4c8d0 GM |
963 | |
964 | @example | |
965 | @group | |
966 | (defun change-property (symbol prop function) | |
967 | (let ((value (get symbol prop))) | |
968 | (put symbol prop (funcall function value)))) | |
969 | @end group | |
b8d4c8d0 | 970 | |
b8d4c8d0 GM |
971 | @group |
972 | (defun double-property (symbol prop) | |
5d6ab672 | 973 | (change-property symbol prop (lambda (x) (* 2 x)))) |
b8d4c8d0 GM |
974 | @end group |
975 | @end example | |
976 | ||
b8d4c8d0 | 977 | @noindent |
735cc5ca | 978 | Note that we do not quote the @code{lambda} form. |
b8d4c8d0 | 979 | |
735cc5ca CY |
980 | If you compile the above code, the anonymous function is also |
981 | compiled. This would not happen if, say, you had constructed the | |
982 | anonymous function by quoting it as a list: | |
b8d4c8d0 | 983 | |
edfaf7c0 | 984 | @c Do not unquote this lambda! |
b8d4c8d0 GM |
985 | @example |
986 | @group | |
987 | (defun double-property (symbol prop) | |
edfaf7c0 | 988 | (change-property symbol prop '(lambda (x) (* 2 x)))) |
b8d4c8d0 GM |
989 | @end group |
990 | @end example | |
991 | ||
992 | @noindent | |
735cc5ca CY |
993 | In that case, the anonymous function is kept as a lambda expression in |
994 | the compiled code. The byte-compiler cannot assume this list is a | |
995 | function, even though it looks like one, since it does not know that | |
996 | @code{change-property} intends to use it as a function. | |
b8d4c8d0 GM |
997 | |
998 | @node Function Cells | |
999 | @section Accessing Function Cell Contents | |
1000 | ||
1001 | The @dfn{function definition} of a symbol is the object stored in the | |
1002 | function cell of the symbol. The functions described here access, test, | |
1003 | and set the function cell of symbols. | |
1004 | ||
1005 | See also the function @code{indirect-function}. @xref{Definition of | |
1006 | indirect-function}. | |
1007 | ||
1008 | @defun symbol-function symbol | |
1009 | @kindex void-function | |
0f1d2934 CY |
1010 | This returns the object in the function cell of @var{symbol}. It does |
1011 | not check that the returned object is a legitimate function. | |
b8d4c8d0 | 1012 | |
0f1d2934 CY |
1013 | If the function cell is void, the return value is @code{nil}. To |
1014 | distinguish between a function cell that is void and one set to | |
1015 | @code{nil}, use @code{fboundp} (see below). | |
b8d4c8d0 GM |
1016 | |
1017 | @example | |
1018 | @group | |
1019 | (defun bar (n) (+ n 2)) | |
b8d4c8d0 GM |
1020 | (symbol-function 'bar) |
1021 | @result{} (lambda (n) (+ n 2)) | |
1022 | @end group | |
1023 | @group | |
1024 | (fset 'baz 'bar) | |
1025 | @result{} bar | |
1026 | @end group | |
1027 | @group | |
1028 | (symbol-function 'baz) | |
1029 | @result{} bar | |
1030 | @end group | |
1031 | @end example | |
1032 | @end defun | |
1033 | ||
1034 | @cindex void function cell | |
0f1d2934 CY |
1035 | If you have never given a symbol any function definition, we say |
1036 | that that symbol's function cell is @dfn{void}. In other words, the | |
1037 | function cell does not have any Lisp object in it. If you try to call | |
1038 | the symbol as a function, Emacs signals a @code{void-function} error. | |
b8d4c8d0 GM |
1039 | |
1040 | Note that void is not the same as @code{nil} or the symbol | |
1041 | @code{void}. The symbols @code{nil} and @code{void} are Lisp objects, | |
1042 | and can be stored into a function cell just as any other object can be | |
1043 | (and they can be valid functions if you define them in turn with | |
1044 | @code{defun}). A void function cell contains no object whatsoever. | |
1045 | ||
1046 | You can test the voidness of a symbol's function definition with | |
1047 | @code{fboundp}. After you have given a symbol a function definition, you | |
1048 | can make it void once more using @code{fmakunbound}. | |
1049 | ||
1050 | @defun fboundp symbol | |
1051 | This function returns @code{t} if the symbol has an object in its | |
1052 | function cell, @code{nil} otherwise. It does not check that the object | |
1053 | is a legitimate function. | |
1054 | @end defun | |
1055 | ||
1056 | @defun fmakunbound symbol | |
1057 | This function makes @var{symbol}'s function cell void, so that a | |
1058 | subsequent attempt to access this cell will cause a | |
1059 | @code{void-function} error. It returns @var{symbol}. (See also | |
1060 | @code{makunbound}, in @ref{Void Variables}.) | |
1061 | ||
1062 | @example | |
1063 | @group | |
1064 | (defun foo (x) x) | |
b8d4c8d0 GM |
1065 | (foo 1) |
1066 | @result{}1 | |
1067 | @end group | |
1068 | @group | |
1069 | (fmakunbound 'foo) | |
1070 | @result{} foo | |
1071 | @end group | |
1072 | @group | |
1073 | (foo 1) | |
1074 | @error{} Symbol's function definition is void: foo | |
1075 | @end group | |
1076 | @end example | |
1077 | @end defun | |
1078 | ||
1079 | @defun fset symbol definition | |
1080 | This function stores @var{definition} in the function cell of | |
1081 | @var{symbol}. The result is @var{definition}. Normally | |
1082 | @var{definition} should be a function or the name of a function, but | |
1083 | this is not checked. The argument @var{symbol} is an ordinary evaluated | |
1084 | argument. | |
1085 | ||
122ff675 SM |
1086 | The primary use of this function is as a subroutine by constructs that define |
1087 | or alter functions, like @code{defun} or @code{advice-add} (@pxref{Advising | |
1088 | Functions}). You can also use it to give a symbol a function definition that | |
1089 | is not a function, e.g., a keyboard macro (@pxref{Keyboard Macros}): | |
b8d4c8d0 | 1090 | |
735cc5ca CY |
1091 | @example |
1092 | ;; @r{Define a named keyboard macro.} | |
1093 | (fset 'kill-two-lines "\^u2\^k") | |
1094 | @result{} "\^u2\^k" | |
1095 | @end example | |
b8d4c8d0 | 1096 | |
735cc5ca CY |
1097 | It you wish to use @code{fset} to make an alternate name for a |
1098 | function, consider using @code{defalias} instead. @xref{Definition of | |
1099 | defalias}. | |
1100 | @end defun | |
b8d4c8d0 | 1101 | |
735cc5ca CY |
1102 | @node Closures |
1103 | @section Closures | |
b8d4c8d0 | 1104 | |
735cc5ca CY |
1105 | As explained in @ref{Variable Scoping}, Emacs can optionally enable |
1106 | lexical binding of variables. When lexical binding is enabled, any | |
1df7defd | 1107 | named function that you create (e.g., with @code{defun}), as well as |
735cc5ca CY |
1108 | any anonymous function that you create using the @code{lambda} macro |
1109 | or the @code{function} special form or the @code{#'} syntax | |
1110 | (@pxref{Anonymous Functions}), is automatically converted into a | |
a08eadfe | 1111 | @dfn{closure}. |
b8d4c8d0 | 1112 | |
9f6f4845 | 1113 | @cindex closure |
735cc5ca CY |
1114 | A closure is a function that also carries a record of the lexical |
1115 | environment that existed when the function was defined. When it is | |
1116 | invoked, any lexical variable references within its definition use the | |
1117 | retained lexical environment. In all other respects, closures behave | |
1118 | much like ordinary functions; in particular, they can be called in the | |
1119 | same way as ordinary functions. | |
b8d4c8d0 | 1120 | |
735cc5ca | 1121 | @xref{Lexical Binding}, for an example of using a closure. |
b8d4c8d0 | 1122 | |
735cc5ca CY |
1123 | Currently, an Emacs Lisp closure object is represented by a list |
1124 | with the symbol @code{closure} as the first element, a list | |
1125 | representing the lexical environment as the second element, and the | |
1126 | argument list and body forms as the remaining elements: | |
b8d4c8d0 | 1127 | |
735cc5ca CY |
1128 | @example |
1129 | ;; @r{lexical binding is enabled.} | |
1130 | (lambda (x) (* x x)) | |
1131 | @result{} (closure (t) (x) (* x x)) | |
b8d4c8d0 | 1132 | @end example |
b8d4c8d0 | 1133 | |
735cc5ca CY |
1134 | @noindent |
1135 | However, the fact that the internal structure of a closure is | |
1136 | ``exposed'' to the rest of the Lisp world is considered an internal | |
1137 | implementation detail. For this reason, we recommend against directly | |
1138 | examining or altering the structure of closure objects. | |
b8d4c8d0 | 1139 | |
122ff675 SM |
1140 | @node Advising Functions |
1141 | @section Advising Emacs Lisp Functions | |
1142 | @cindex advising functions | |
1143 | @cindex piece of advice | |
1144 | ||
6c187ef5 SM |
1145 | When you need to modify a function defined in another library, or when you need |
1146 | to modify a hook like @code{@var{foo}-function}, a process filter, or basically | |
1147 | any variable or object field which holds a function value, you can use the | |
1148 | appropriate setter function, such as @code{fset} or @code{defun} for named | |
1149 | functions, @code{setq} for hook variables, or @code{set-process-filter} for | |
1150 | process filters, but those are often too blunt, completely throwing away the | |
122ff675 SM |
1151 | previous value. |
1152 | ||
6c187ef5 SM |
1153 | The @dfn{advice} feature lets you add to the existing definition of |
1154 | a function, by @dfn{advising the function}. This is a cleaner method | |
1155 | than redefining the whole function. | |
122ff675 | 1156 | |
6c187ef5 SM |
1157 | Emacs's advice system provides two sets of primitives for that: the core set, |
1158 | for function values held in variables and object fields (with the corresponding | |
1159 | primitives being @code{add-function} and @code{remove-function}) and another | |
1160 | set layered on top of it for named functions (with the main primitives being | |
1161 | @code{advice-add} and @code{advice-remove}). | |
1162 | ||
1163 | For example, in order to trace the calls to the process filter of a process | |
1164 | @var{proc}, you could use: | |
122ff675 SM |
1165 | |
1166 | @example | |
6c187ef5 SM |
1167 | (defun my-tracing-function (proc string) |
1168 | (message "Proc %S received %S" proc string)) | |
1169 | ||
1170 | (add-function :before (process-filter @var{proc}) #'my-tracing-function) | |
122ff675 SM |
1171 | @end example |
1172 | ||
0c0ec041 SM |
1173 | This will cause the process's output to be passed to @code{my-tracing-function} |
1174 | before being passed to the original process filter. @code{my-tracing-function} | |
1175 | receives the same arguments as the original function. When you're done with | |
1176 | it, you can revert to the untraced behavior with: | |
122ff675 SM |
1177 | |
1178 | @example | |
6c187ef5 | 1179 | (remove-function (process-filter @var{proc}) #'my-tracing-function) |
122ff675 SM |
1180 | @end example |
1181 | ||
6c187ef5 SM |
1182 | Similarly, if you want to trace the execution of the function named |
1183 | @code{display-buffer}, you could use: | |
1184 | ||
1185 | @example | |
1186 | (defun his-tracing-function (orig-fun &rest args) | |
1187 | (message "display-buffer called with args %S" args) | |
1188 | (let ((res (apply orig-fun args))) | |
1189 | (message "display-buffer returned %S" res) | |
1190 | res)) | |
1191 | ||
1192 | (advice-add 'display-buffer :around #'his-tracing-function) | |
1193 | @end example | |
122ff675 | 1194 | |
0c0ec041 SM |
1195 | Here, @code{his-tracing-function} is called instead of the original function |
1196 | and receives the original function (additionally to that function's arguments) | |
1197 | as argument, so it can call it if and when it needs to. | |
1198 | When you're tired of seeing this output, you can revert to the untraced | |
6c187ef5 SM |
1199 | behavior with: |
1200 | ||
1201 | @example | |
1202 | (advice-remove 'display-buffer #'his-tracing-function) | |
1203 | @end example | |
1204 | ||
0c0ec041 | 1205 | The arguments @code{:before} and @code{:around} used in the above examples |
6c187ef5 SM |
1206 | specify how the two functions are composed, since there are many different |
1207 | ways to do it. The added function is also called an @emph{advice}. | |
122ff675 SM |
1208 | |
1209 | @menu | |
6c187ef5 SM |
1210 | * Core Advising Primitives:: Primitives to Manipulate Advices |
1211 | * Advising Named Functions:: Advising Named Functions | |
0c0ec041 | 1212 | * Advice combinators:: Ways to compose advices |
6c187ef5 | 1213 | * Porting old advices:: Adapting code using the old defadvice |
122ff675 SM |
1214 | @end menu |
1215 | ||
6c187ef5 SM |
1216 | @node Core Advising Primitives |
1217 | @subsection Primitives to manipulate advices | |
122ff675 SM |
1218 | |
1219 | @defmac add-function where place function &optional props | |
1220 | This macro is the handy way to add the advice @var{function} to the function | |
1221 | stored in @var{place} (@pxref{Generalized Variables}). | |
1222 | ||
6c187ef5 SM |
1223 | If @var{function} is not interactive, then the combined function will inherit |
1224 | the interactive spec, if any, of the original function. Else, the combined | |
1225 | function will be interactive and will use the interactive spec of | |
1226 | @var{function}. One exception: if the interactive spec of @var{function} | |
1227 | is a function (rather than an expression or a string), then the interactive | |
1228 | spec of the combined function will be a call to that function with as sole | |
1229 | argument the interactive spec of the original function. To interpret the spec | |
1230 | received as argument, use @code{advice-eval-interactive-spec}. | |
1231 | ||
122ff675 | 1232 | @var{where} determines how @var{function} is composed with the |
0c0ec041 | 1233 | existing function, e.g. whether @var{function} should be called before, or |
45681788 | 1234 | after the original function. @xref{Advice combinators}, for the list of |
0c0ec041 | 1235 | available ways to compose the two functions. |
122ff675 SM |
1236 | |
1237 | When modifying a variable (whose name will usually end with @code{-function}), | |
1238 | you can choose whether @var{function} is used globally or only in the current | |
1239 | buffer: if @var{place} is just a symbol, then @var{function} is added to the | |
1240 | global value of @var{place}. Whereas if @var{place} is of the form | |
1241 | @code{(local @var{symbol})}, where @var{symbol} is an expression which returns | |
1242 | the variable name, then @var{function} will only be added in the | |
5d03fb43 SM |
1243 | current buffer. Finally, if you want to modify a lexical variable, you will |
1244 | have to use @code{(var @var{VARIABLE})}. | |
122ff675 SM |
1245 | |
1246 | Every function added with @code{add-function} can be accompanied by an | |
1247 | association list of properties @var{props}. Currently only two of those | |
1248 | properties have a special meaning: | |
1249 | ||
1250 | @table @code | |
1251 | @item name | |
1252 | This gives a name to the advice, which @code{remove-function} can use to | |
1253 | identify which function to remove. Typically used when @var{function} is an | |
1254 | anonymous function. | |
1255 | ||
1256 | @item depth | |
0c0ec041 | 1257 | This specifies how to order the advices, in case several advices are present. |
122ff675 SM |
1258 | By default, the depth is 0. A depth of 100 indicates that this advice should |
1259 | be kept as deep as possible, whereas a depth of -100 indicates that it | |
1260 | should stay as the outermost advice. When two advices specify the same depth, | |
1261 | the most recently added advice will be outermost. | |
0c0ec041 SM |
1262 | |
1263 | For a @code{:before} advice, being outermost means that this advice will be run | |
1264 | first, before any other advice, whereas being innermost means that it will run | |
1265 | right before the original function, with no other advice run between itself and | |
1266 | the original function. Similarly, for an @code{:after} advice innermost means | |
1267 | that it will run right after the original function, with no other advice run in | |
1268 | between, whereas outermost means that it will be run very last after all | |
1269 | other advices. An innermost @code{:override} advice will only override the | |
1270 | original function and other advices will apply to it, whereas an outermost | |
1271 | @code{:override} advice will override not only the original function but all | |
1272 | other advices applied to it as well. | |
122ff675 SM |
1273 | @end table |
1274 | @end defmac | |
1275 | ||
1276 | @defmac remove-function place function | |
1277 | This macro removes @var{function} from the function stored in | |
1278 | @var{place}. This only works if @var{function} was added to @var{place} | |
1279 | using @code{add-function}. | |
1280 | ||
1281 | @var{function} is compared with functions added to @var{place} using | |
1282 | @code{equal}, to try and make it work also with lambda expressions. It is | |
1283 | additionally compared also with the @code{name} property of the functions added | |
1284 | to @var{place}, which can be more reliable than comparing lambda expressions | |
1285 | using @code{equal}. | |
1286 | @end defmac | |
1287 | ||
1288 | @defun advice-function-member-p advice function-def | |
1289 | Return non-@code{nil} if @var{advice} is already in @var{function-def}. | |
1290 | Like for @code{remove-function} above, instead of @var{advice} being the actual | |
1291 | function, it can also be the @code{name} of the piece of advice. | |
1292 | @end defun | |
1293 | ||
1294 | @defun advice-function-mapc f function-def | |
1295 | Call the function @var{f} for every advice that was added to | |
1296 | @var{function-def}. @var{f} is called with two arguments: the advice function | |
1297 | and its properties. | |
1298 | @end defun | |
1299 | ||
6c187ef5 SM |
1300 | @defun advice-eval-interactive-spec spec |
1301 | Evaluate the interactive @var{spec} just like an interactive call to a function | |
1302 | with such a spec would, and then return the corresponding list of arguments | |
1303 | that was built. E.g. @code{(advice-eval-interactive-spec "r\nP")} will | |
1304 | return a list of three elements, containing the boundaries of the region and | |
1305 | the current prefix argument. | |
1306 | @end defun | |
1307 | ||
122ff675 SM |
1308 | @node Advising Named Functions |
1309 | @subsection Advising Named Functions | |
1310 | ||
1311 | A common use of advice is for named functions and macros. | |
6c187ef5 SM |
1312 | You could just use @code{add-function} as in: |
1313 | ||
1314 | @example | |
1315 | (add-function :around (symbol-function '@var{fun}) #'his-tracing-function) | |
1316 | @end example | |
1317 | ||
1318 | But you should use @code{advice-add} and @code{advice-remove} for that | |
1319 | instead. This separate set of functions to manipulate pieces of advice applied | |
1320 | to named functions, offers the following extra features compared to | |
1321 | @code{add-function}: they know how to deal with macros and autoloaded | |
1322 | functions, they let @code{describe-function} preserve the original docstring as | |
1323 | well as document the added advice, and they let you add and remove advices | |
1324 | before a function is even defined. | |
1325 | ||
1326 | @code{advice-add} can be useful for altering the behavior of existing calls | |
1327 | to an existing function without having to redefine the whole function. | |
1328 | However, it can be a source of bugs, since existing callers to the function may | |
1329 | assume the old behavior, and work incorrectly when the behavior is changed by | |
1330 | advice. Advice can also cause confusion in debugging, if the person doing the | |
1331 | debugging does not notice or remember that the function has been modified | |
1332 | by advice. | |
122ff675 SM |
1333 | |
1334 | For these reasons, advice should be reserved for the cases where you | |
1335 | cannot modify a function's behavior in any other way. If it is | |
1336 | possible to do the same thing via a hook, that is preferable | |
1337 | (@pxref{Hooks}). If you simply want to change what a particular key | |
1338 | does, it may be better to write a new command, and remap the old | |
1339 | command's key bindings to the new one (@pxref{Remapping Commands}). | |
1340 | In particular, Emacs's own source files should not put advice on | |
1341 | functions in Emacs. (There are currently a few exceptions to this | |
1342 | convention, but we aim to correct them.) | |
1343 | ||
0c0ec041 SM |
1344 | Special forms (@pxref{Special Forms}) cannot be advised, however macros can |
1345 | be advised, in much the same way as functions. Of course, this will not affect | |
1346 | code that has already been macro-expanded, so you need to make sure the advice | |
1347 | is installed before the macro is expanded. | |
122ff675 SM |
1348 | |
1349 | It is possible to advise a primitive (@pxref{What Is a Function}), | |
1350 | but one should typically @emph{not} do so, for two reasons. Firstly, | |
1351 | some primitives are used by the advice mechanism, and advising them | |
1352 | could cause an infinite recursion. Secondly, many primitives are | |
1353 | called directly from C, and such calls ignore advice; hence, one ends | |
1354 | up in a confusing situation where some calls (occurring from Lisp | |
1355 | code) obey the advice and other calls (from C code) do not. | |
1356 | ||
1357 | @defun advice-add symbol where function &optional props | |
1358 | Add the advice @var{function} to the named function @var{symbol}. | |
1359 | @var{where} and @var{props} have the same meaning as for @code{add-function} | |
28a51720 | 1360 | (@pxref{Core Advising Primitives}). |
122ff675 SM |
1361 | @end defun |
1362 | ||
1363 | @defun advice-remove symbol function | |
1364 | Remove the advice @var{function} from the named function @var{symbol}. | |
1365 | @var{function} can also be the @code{name} of an advice. | |
1366 | @end defun | |
1367 | ||
1368 | @defun advice-member-p function symbol | |
1369 | Return non-@code{nil} if the advice @var{function} is already in the named | |
1370 | function @var{symbol}. @var{function} can also be the @code{name} of | |
1371 | an advice. | |
1372 | @end defun | |
1373 | ||
1374 | @defun advice-mapc function symbol | |
1375 | Call @var{function} for every advice that was added to the named function | |
1376 | @var{symbol}. @var{function} is called with two arguments: the advice function | |
1377 | and its properties. | |
1378 | @end defun | |
1379 | ||
0c0ec041 SM |
1380 | @node Advice combinators |
1381 | @subsection Ways to compose advices | |
1382 | ||
1383 | Here are the different possible values for the @var{where} argument of | |
1384 | @code{add-function} and @code{advice-add}, specifying how the advice | |
1385 | @var{function} and the original function should be composed. | |
1386 | ||
1387 | @table @code | |
1388 | @item :before | |
1389 | Call @var{function} before the old function. Both functions receive the | |
1390 | same arguments, and the return value of the composition is the return value of | |
1391 | the old function. More specifically, the composition of the two functions | |
1392 | behaves like: | |
1393 | @example | |
1394 | (lambda (&rest r) (apply @var{function} r) (apply @var{oldfun} r)) | |
1395 | @end example | |
1396 | @code{(add-function :before @var{funvar} @var{function})} is comparable for | |
1397 | single-function hooks to @code{(add-hook '@var{hookvar} @var{function})} for | |
1398 | normal hooks. | |
1399 | ||
1400 | @item :after | |
1401 | Call @var{function} after the old function. Both functions receive the | |
1402 | same arguments, and the return value of the composition is the return value of | |
1403 | the old function. More specifically, the composition of the two functions | |
1404 | behaves like: | |
1405 | @example | |
1406 | (lambda (&rest r) (prog1 (apply @var{oldfun} r) (apply @var{function} r))) | |
1407 | @end example | |
1408 | @code{(add-function :after @var{funvar} @var{function})} is comparable for | |
1409 | single-function hooks to @code{(add-hook '@var{hookvar} @var{function} | |
1410 | 'append)} for normal hooks. | |
1411 | ||
1412 | @item :override | |
1413 | This completely replaces the old function with the new one. The old function | |
1414 | can of course be recovered if you later call @code{remove-function}. | |
1415 | ||
1416 | @item :around | |
1417 | Call @var{function} instead of the old function, but provide the old function | |
1418 | as an extra argument to @var{function}. This is the most flexible composition. | |
1419 | For example, it lets you call the old function with different arguments, or | |
1420 | many times, or within a let-binding, or you can sometimes delegate the work to | |
1421 | the old function and sometimes override it completely. More specifically, the | |
1422 | composition of the two functions behaves like: | |
1423 | @example | |
1424 | (lambda (&rest r) (apply @var{function} @var{oldfun} r)) | |
1425 | @end example | |
1426 | ||
1427 | @item :before-while | |
1428 | Call @var{function} before the old function and don't call the old | |
1429 | function if @var{function} returns @code{nil}. Both functions receive the | |
1430 | same arguments, and the return value of the composition is the return value of | |
1431 | the old function. More specifically, the composition of the two functions | |
1432 | behaves like: | |
1433 | @example | |
1434 | (lambda (&rest r) (and (apply @var{function} r) (apply @var{oldfun} r))) | |
1435 | @end example | |
1436 | @code{(add-function :before-while @var{funvar} @var{function})} is comparable | |
1437 | for single-function hooks to @code{(add-hook '@var{hookvar} @var{function})} | |
1438 | when @var{hookvar} is run via @code{run-hook-with-args-until-failure}. | |
1439 | ||
1440 | @item :before-until | |
1441 | Call @var{function} before the old function and only call the old function if | |
1442 | @var{function} returns @code{nil}. More specifically, the composition of the | |
1443 | two functions behaves like: | |
1444 | @example | |
1445 | (lambda (&rest r) (or (apply @var{function} r) (apply @var{oldfun} r))) | |
1446 | @end example | |
1447 | @code{(add-function :before-until @var{funvar} @var{function})} is comparable | |
1448 | for single-function hooks to @code{(add-hook '@var{hookvar} @var{function})} | |
1449 | when @var{hookvar} is run via @code{run-hook-with-args-until-success}. | |
1450 | ||
1451 | @item :after-while | |
1452 | Call @var{function} after the old function and only if the old function | |
1453 | returned non-@code{nil}. Both functions receive the same arguments, and the | |
1454 | return value of the composition is the return value of @var{function}. | |
1455 | More specifically, the composition of the two functions behaves like: | |
1456 | @example | |
1457 | (lambda (&rest r) (and (apply @var{oldfun} r) (apply @var{function} r))) | |
1458 | @end example | |
1459 | @code{(add-function :after-while @var{funvar} @var{function})} is comparable | |
1460 | for single-function hooks to @code{(add-hook '@var{hookvar} @var{function} | |
1461 | 'append)} when @var{hookvar} is run via | |
1462 | @code{run-hook-with-args-until-failure}. | |
1463 | ||
1464 | @item :after-until | |
1465 | Call @var{function} after the old function and only if the old function | |
1466 | returned @code{nil}. More specifically, the composition of the two functions | |
1467 | behaves like: | |
1468 | @example | |
1469 | (lambda (&rest r) (or (apply @var{oldfun} r) (apply @var{function} r))) | |
1470 | @end example | |
1471 | @code{(add-function :after-until @var{funvar} @var{function})} is comparable | |
1472 | for single-function hooks to @code{(add-hook '@var{hookvar} @var{function} | |
1473 | 'append)} when @var{hookvar} is run via | |
1474 | @code{run-hook-with-args-until-success}. | |
1475 | ||
1476 | @item :filter-args | |
1477 | Call @var{function} first and use the result (which should be a list) as the | |
1478 | new arguments to pass to the old function. More specifically, the composition | |
1479 | of the two functions behaves like: | |
1480 | @example | |
1481 | (lambda (&rest r) (apply @var{oldfun} (funcall @var{function} r))) | |
1482 | @end example | |
1483 | ||
1484 | @item :filter-return | |
1485 | Call the old function first and pass the result to @var{function}. | |
1486 | More specifically, the composition of the two functions behaves like: | |
1487 | @example | |
1488 | (lambda (&rest r) (funcall @var{function} (apply @var{oldfun} r))) | |
1489 | @end example | |
1490 | @end table | |
1491 | ||
1492 | ||
6c187ef5 SM |
1493 | @node Porting old advices |
1494 | @subsection Adapting code using the old defadvice | |
1495 | ||
1496 | A lot of code uses the old @code{defadvice} mechanism, which is largely made | |
1497 | obsolete by the new @code{advice-add}, whose implementation and semantics is | |
1498 | significantly simpler. | |
1499 | ||
1500 | An old advice such as: | |
1501 | ||
1502 | @example | |
1503 | (defadvice previous-line (before next-line-at-end | |
1504 | (&optional arg try-vscroll)) | |
1505 | "Insert an empty line when moving up from the top line." | |
1506 | (if (and next-line-add-newlines (= arg 1) | |
1507 | (save-excursion (beginning-of-line) (bobp))) | |
1508 | (progn | |
1509 | (beginning-of-line) | |
1510 | (newline)))) | |
1511 | @end example | |
1512 | ||
1513 | could be translated in the new advice mechanism into a plain function: | |
1514 | ||
1515 | @example | |
1516 | (defun previous-line--next-line-at-end (&optional arg try-vscroll) | |
1517 | "Insert an empty line when moving up from the top line." | |
1518 | (if (and next-line-add-newlines (= arg 1) | |
1519 | (save-excursion (beginning-of-line) (bobp))) | |
1520 | (progn | |
1521 | (beginning-of-line) | |
1522 | (newline)))) | |
1523 | @end example | |
1524 | ||
1525 | Obviously, this does not actually modify @code{previous-line}. For that the | |
1526 | old advice needed: | |
1527 | @example | |
1528 | (ad-activate 'previous-line) | |
1529 | @end example | |
1530 | whereas the new advice mechanism needs: | |
1531 | @example | |
1532 | (advice-add 'previous-line :before #'previous-line--next-line-at-end) | |
1533 | @end example | |
1534 | ||
1535 | Note that @code{ad-activate} had a global effect: it activated all pieces of | |
1536 | advice enabled for that specified function. If you wanted to only activate or | |
1537 | deactivate a particular advice, you needed to @emph{enable} or @emph{disable} | |
1538 | that advice with @code{ad-enable-advice} and @code{ad-disable-advice}. | |
1539 | The new mechanism does away with this distinction. | |
1540 | ||
1541 | An around advice such as: | |
1542 | ||
1543 | @example | |
1544 | (defadvice foo (around foo-around) | |
1545 | "Ignore case in `foo'." | |
1546 | (let ((case-fold-search t)) | |
1547 | ad-do-it)) | |
1548 | (ad-activate 'foo) | |
1549 | @end example | |
1550 | ||
1551 | could translate into: | |
1552 | ||
1553 | @example | |
1554 | (defun foo--foo-around (orig-fun &rest args) | |
1555 | "Ignore case in `foo'." | |
1556 | (let ((case-fold-search t)) | |
1557 | (apply orig-fun args))) | |
1558 | (advice-add 'foo :around #'foo--foo-around) | |
1559 | @end example | |
1560 | ||
1561 | Regarding the advice's @emph{class}, note that the new @code{:before} is not | |
1562 | quite equivalent to the old @code{before}, because in the old advice you could | |
1563 | modify the function's arguments (e.g., with @code{ad-set-arg}), and that would | |
1564 | affect the argument values seen by the original function, whereas in the new | |
1565 | @code{:before}, modifying an argument via @code{setq} in the advice has no | |
1566 | effect on the arguments seen by the original function. | |
1567 | When porting a @code{before} advice which relied on this behavior, you'll need | |
1568 | to turn it into a new @code{:around} or @code{:filter-args} advice instead. | |
1569 | ||
1570 | Similarly an old @code{after} advice could modify the returned value by | |
1571 | changing @code{ad-return-value}, whereas a new @code{:after} advice cannot, so | |
1572 | when porting such an old @code{after} advice, you'll need to turn it into a new | |
1573 | @code{:around} or @code{:filter-return} advice instead. | |
1574 | ||
b8d4c8d0 GM |
1575 | @node Obsolete Functions |
1576 | @section Declaring Functions Obsolete | |
99d8e6d6 | 1577 | @cindex obsolete functions |
b8d4c8d0 | 1578 | |
48de8b12 CY |
1579 | You can mark a named function as @dfn{obsolete}, meaning that it may |
1580 | be removed at some point in the future. This causes Emacs to warn | |
1581 | that the function is obsolete whenever it byte-compiles code | |
1582 | containing that function, and whenever it displays the documentation | |
1583 | for that function. In all other respects, an obsolete function | |
1584 | behaves like any other function. | |
1585 | ||
1586 | The easiest way to mark a function as obsolete is to put a | |
1587 | @code{(declare (obsolete @dots{}))} form in the function's | |
1588 | @code{defun} definition. @xref{Declare Form}. Alternatively, you can | |
1589 | use the @code{make-obsolete} function, described below. | |
1590 | ||
1591 | A macro (@pxref{Macros}) can also be marked obsolete with | |
1592 | @code{make-obsolete}; this has the same effects as for a function. An | |
1593 | alias for a function or macro can also be marked as obsolete; this | |
1594 | makes the alias itself obsolete, not the function or macro which it | |
1595 | resolves to. | |
b8d4c8d0 GM |
1596 | |
1597 | @defun make-obsolete obsolete-name current-name &optional when | |
48de8b12 CY |
1598 | This function marks @var{obsolete-name} as obsolete. |
1599 | @var{obsolete-name} should be a symbol naming a function or macro, or | |
1600 | an alias for a function or macro. | |
1601 | ||
1602 | If @var{current-name} is a symbol, the warning message says to use | |
1603 | @var{current-name} instead of @var{obsolete-name}. @var{current-name} | |
1604 | does not need to be an alias for @var{obsolete-name}; it can be a | |
1605 | different function with similar functionality. @var{current-name} can | |
1606 | also be a string, which serves as the warning message. The message | |
1607 | should begin in lower case, and end with a period. It can also be | |
1608 | @code{nil}, in which case the warning message provides no additional | |
1609 | details. | |
b8d4c8d0 GM |
1610 | |
1611 | If provided, @var{when} should be a string indicating when the function | |
1612 | was first made obsolete---for example, a date or a release number. | |
1613 | @end defun | |
1614 | ||
d18a0d24 | 1615 | @defmac define-obsolete-function-alias obsolete-name current-name &optional when doc |
48de8b12 CY |
1616 | This convenience macro marks the function @var{obsolete-name} obsolete |
1617 | and also defines it as an alias for the function @var{current-name}. | |
1618 | It is equivalent to the following: | |
b8d4c8d0 GM |
1619 | |
1620 | @example | |
d18a0d24 | 1621 | (defalias @var{obsolete-name} @var{current-name} @var{doc}) |
b8d4c8d0 GM |
1622 | (make-obsolete @var{obsolete-name} @var{current-name} @var{when}) |
1623 | @end example | |
1624 | @end defmac | |
1625 | ||
eb5ed549 CY |
1626 | In addition, you can mark a certain a particular calling convention |
1627 | for a function as obsolete: | |
1628 | ||
27d1f87a | 1629 | @defun set-advertised-calling-convention function signature when |
eb5ed549 CY |
1630 | This function specifies the argument list @var{signature} as the |
1631 | correct way to call @var{function}. This causes the Emacs byte | |
1632 | compiler to issue a warning whenever it comes across an Emacs Lisp | |
1633 | program that calls @var{function} any other way (however, it will | |
27d1f87a CY |
1634 | still allow the code to be byte compiled). @var{when} should be a |
1635 | string indicating when the variable was first made obsolete (usually a | |
1636 | version number string). | |
eb5ed549 CY |
1637 | |
1638 | For instance, in old versions of Emacs the @code{sit-for} function | |
1639 | accepted three arguments, like this | |
1640 | ||
ddff3351 | 1641 | @example |
eb5ed549 | 1642 | (sit-for seconds milliseconds nodisp) |
ddff3351 | 1643 | @end example |
eb5ed549 CY |
1644 | |
1645 | However, calling @code{sit-for} this way is considered obsolete | |
1646 | (@pxref{Waiting}). The old calling convention is deprecated like | |
1647 | this: | |
1648 | ||
ddff3351 | 1649 | @example |
eb5ed549 | 1650 | (set-advertised-calling-convention |
27d1f87a | 1651 | 'sit-for '(seconds &optional nodisp) "22.1") |
ddff3351 | 1652 | @end example |
eb5ed549 CY |
1653 | @end defun |
1654 | ||
b8d4c8d0 GM |
1655 | @node Inline Functions |
1656 | @section Inline Functions | |
1657 | @cindex inline functions | |
1658 | ||
d18a0d24 CY |
1659 | An @dfn{inline function} is a function that works just like an |
1660 | ordinary function, except for one thing: when you byte-compile a call | |
735cc5ca | 1661 | to the function (@pxref{Byte Compilation}), the function's definition |
d18a0d24 CY |
1662 | is expanded into the caller. To define an inline function, use |
1663 | @code{defsubst} instead of @code{defun}. | |
1664 | ||
1665 | @defmac defsubst name args [doc] [declare] [interactive] body@dots{} | |
1666 | This macro defines an inline function. Its syntax is exactly the same | |
1667 | as @code{defun} (@pxref{Defining Functions}). | |
1668 | @end defmac | |
b8d4c8d0 | 1669 | |
735cc5ca CY |
1670 | Making a function inline often makes its function calls run faster. |
1671 | But it also has disadvantages. For one thing, it reduces flexibility; | |
1672 | if you change the definition of the function, calls already inlined | |
1673 | still use the old definition until you recompile them. | |
b8d4c8d0 | 1674 | |
735cc5ca CY |
1675 | Another disadvantage is that making a large function inline can |
1676 | increase the size of compiled code both in files and in memory. Since | |
1677 | the speed advantage of inline functions is greatest for small | |
1678 | functions, you generally should not make large functions inline. | |
b8d4c8d0 | 1679 | |
735cc5ca | 1680 | Also, inline functions do not behave well with respect to debugging, |
b8d4c8d0 GM |
1681 | tracing, and advising (@pxref{Advising Functions}). Since ease of |
1682 | debugging and the flexibility of redefining functions are important | |
1683 | features of Emacs, you should not make a function inline, even if it's | |
1684 | small, unless its speed is really crucial, and you've timed the code | |
1685 | to verify that using @code{defun} actually has performance problems. | |
1686 | ||
735cc5ca CY |
1687 | It's possible to define a macro to expand into the same code that an |
1688 | inline function would execute (@pxref{Macros}). But the macro would | |
1689 | be limited to direct use in expressions---a macro cannot be called | |
1690 | with @code{apply}, @code{mapcar} and so on. Also, it takes some work | |
1691 | to convert an ordinary function into a macro. To convert it into an | |
1692 | inline function is easy; just replace @code{defun} with | |
1693 | @code{defsubst}. Since each argument of an inline function is | |
1694 | evaluated exactly once, you needn't worry about how many times the | |
1695 | body uses the arguments, as you do for macros. | |
b8d4c8d0 | 1696 | |
735cc5ca CY |
1697 | After an inline function is defined, its inline expansion can be |
1698 | performed later on in the same file, just like macros. | |
b8d4c8d0 | 1699 | |
48de8b12 CY |
1700 | @node Declare Form |
1701 | @section The @code{declare} Form | |
1702 | @findex declare | |
1703 | ||
1704 | @code{declare} is a special macro which can be used to add ``meta'' | |
1705 | properties to a function or macro: for example, marking it as | |
1706 | obsolete, or giving its forms a special @key{TAB} indentation | |
1707 | convention in Emacs Lisp mode. | |
1708 | ||
1709 | @anchor{Definition of declare} | |
151d9088 | 1710 | @defmac declare specs@dots{} |
48de8b12 | 1711 | This macro ignores its arguments and evaluates to @code{nil}; it has |
d18a0d24 CY |
1712 | no run-time effect. However, when a @code{declare} form occurs in the |
1713 | @var{declare} argument of a @code{defun} or @code{defsubst} function | |
1714 | definition (@pxref{Defining Functions}) or a @code{defmacro} macro | |
1715 | definition (@pxref{Defining Macros}), it appends the properties | |
1716 | specified by @var{specs} to the function or macro. This work is | |
1717 | specially performed by @code{defun}, @code{defsubst}, and | |
1718 | @code{defmacro}. | |
48de8b12 CY |
1719 | |
1720 | Each element in @var{specs} should have the form @code{(@var{property} | |
1721 | @var{args}@dots{})}, which should not be quoted. These have the | |
1722 | following effects: | |
1723 | ||
1724 | @table @code | |
1725 | @item (advertised-calling-convention @var{signature} @var{when}) | |
1726 | This acts like a call to @code{set-advertised-calling-convention} | |
1727 | (@pxref{Obsolete Functions}); @var{signature} specifies the correct | |
1728 | argument list for calling the function or macro, and @var{when} should | |
add6de1c | 1729 | be a string indicating when the old argument list was first made obsolete. |
48de8b12 CY |
1730 | |
1731 | @item (debug @var{edebug-form-spec}) | |
1732 | This is valid for macros only. When stepping through the macro with | |
1733 | Edebug, use @var{edebug-form-spec}. @xref{Instrumenting Macro Calls}. | |
1734 | ||
1735 | @item (doc-string @var{n}) | |
add6de1c SM |
1736 | This is used when defining a function or macro which itself will be used to |
1737 | define entities like functions, macros, or variables. It indicates that | |
1738 | the @var{n}th argument, if any, should be considered | |
1739 | as a documentation string. | |
48de8b12 CY |
1740 | |
1741 | @item (indent @var{indent-spec}) | |
1742 | Indent calls to this function or macro according to @var{indent-spec}. | |
1743 | This is typically used for macros, though it works for functions too. | |
1744 | @xref{Indenting Macros}. | |
1745 | ||
1746 | @item (obsolete @var{current-name} @var{when}) | |
1747 | Mark the function or macro as obsolete, similar to a call to | |
1748 | @code{make-obsolete} (@pxref{Obsolete Functions}). @var{current-name} | |
1749 | should be a symbol (in which case the warning message says to use that | |
1750 | instead), a string (specifying the warning message), or @code{nil} (in | |
1751 | which case the warning message gives no extra details). @var{when} | |
1752 | should be a string indicating when the function or macro was first | |
1753 | made obsolete. | |
add6de1c SM |
1754 | |
1755 | @item (compiler-macro @var{expander}) | |
1756 | This can only be used for functions, and tells the compiler to use | |
1757 | @var{expander} as an optimization function. When encountering a call to the | |
d994ff7c | 1758 | function, of the form @code{(@var{function} @var{args}@dots{})}, the macro |
add6de1c | 1759 | expander will call @var{expander} with that form as well as with |
d994ff7c | 1760 | @var{args}@dots{}, and @var{expander} can either return a new expression to use |
add6de1c SM |
1761 | instead of the function call, or it can return just the form unchanged, |
1762 | to indicate that the function call should be left alone. @var{expander} can | |
1763 | be a symbol, or it can be a form @code{(lambda (@var{arg}) @var{body})} in | |
1764 | which case @var{arg} will hold the original function call expression, and the | |
1765 | (unevaluated) arguments to the function can be accessed using the function's | |
1766 | formal arguments. | |
1767 | ||
1768 | @item (gv-expander @var{expander}) | |
1769 | Declare @var{expander} to be the function to handle calls to the macro (or | |
1770 | function) as a generalized variable, similarly to @code{gv-define-expander}. | |
1771 | @var{expander} can be a symbol or it can be of the form @code{(lambda | |
1772 | (@var{arg}) @var{body})} in which case that function will additionally have | |
1773 | access to the macro (or function)'s arguments. | |
1774 | ||
1775 | @item (gv-setter @var{setter}) | |
1776 | Declare @var{setter} to be the function to handle calls to the macro (or | |
1777 | function) as a generalized variable. @var{setter} can be a symbol in which | |
1778 | case it will be passed to @code{gv-define-simple-setter}, or it can be of the | |
1779 | form @code{(lambda (@var{arg}) @var{body})} in which case that function will | |
1780 | additionally have access to the macro (or function)'s arguments and it will | |
1781 | passed to @code{gv-define-setter}. | |
1782 | ||
48de8b12 | 1783 | @end table |
add6de1c | 1784 | |
48de8b12 CY |
1785 | @end defmac |
1786 | ||
e31dfb12 GM |
1787 | @node Declaring Functions |
1788 | @section Telling the Compiler that a Function is Defined | |
1789 | @cindex function declaration | |
1790 | @cindex declaring functions | |
c4540067 | 1791 | @findex declare-function |
e31dfb12 | 1792 | |
a0925923 RS |
1793 | Byte-compiling a file often produces warnings about functions that the |
1794 | compiler doesn't know about (@pxref{Compiler Errors}). Sometimes this | |
1795 | indicates a real problem, but usually the functions in question are | |
1796 | defined in other files which would be loaded if that code is run. For | |
1797 | example, byte-compiling @file{fortran.el} used to warn: | |
e31dfb12 | 1798 | |
ddff3351 | 1799 | @example |
e31dfb12 | 1800 | In end of data: |
84f4a531 CY |
1801 | fortran.el:2152:1:Warning: the function `gud-find-c-expr' is not |
1802 | known to be defined. | |
ddff3351 | 1803 | @end example |
e31dfb12 | 1804 | |
a0925923 RS |
1805 | In fact, @code{gud-find-c-expr} is only used in the function that |
1806 | Fortran mode uses for the local value of | |
1807 | @code{gud-find-expr-function}, which is a callback from GUD; if it is | |
1808 | called, the GUD functions will be loaded. When you know that such a | |
1809 | warning does not indicate a real problem, it is good to suppress the | |
1810 | warning. That makes new warnings which might mean real problems more | |
1811 | visible. You do that with @code{declare-function}. | |
e31dfb12 GM |
1812 | |
1813 | All you need to do is add a @code{declare-function} statement before the | |
1814 | first use of the function in question: | |
1815 | ||
ddff3351 | 1816 | @example |
e31dfb12 | 1817 | (declare-function gud-find-c-expr "gud.el" nil) |
ddff3351 | 1818 | @end example |
e31dfb12 GM |
1819 | |
1820 | This says that @code{gud-find-c-expr} is defined in @file{gud.el} (the | |
a0925923 RS |
1821 | @samp{.el} can be omitted). The compiler takes for granted that that file |
1822 | really defines the function, and does not check. | |
7a6a1728 | 1823 | |
a0925923 RS |
1824 | The optional third argument specifies the argument list of |
1825 | @code{gud-find-c-expr}. In this case, it takes no arguments | |
1826 | (@code{nil} is different from not specifying a value). In other | |
1827 | cases, this might be something like @code{(file &optional overwrite)}. | |
1828 | You don't have to specify the argument list, but if you do the | |
1829 | byte compiler can check that the calls match the declaration. | |
1830 | ||
8f4b37d8 | 1831 | @defmac declare-function function file &optional arglist fileonly |
a0925923 | 1832 | Tell the byte compiler to assume that @var{function} is defined, with |
b0fbc500 CY |
1833 | arguments @var{arglist}, and that the definition should come from the |
1834 | file @var{file}. @var{fileonly} non-@code{nil} means only check that | |
8f4b37d8 | 1835 | @var{file} exists, not that it actually defines @var{function}. |
a0925923 RS |
1836 | @end defmac |
1837 | ||
1838 | To verify that these functions really are declared where | |
1839 | @code{declare-function} says they are, use @code{check-declare-file} | |
1840 | to check all @code{declare-function} calls in one source file, or use | |
1841 | @code{check-declare-directory} check all the files in and under a | |
1842 | certain directory. | |
1843 | ||
1844 | These commands find the file that ought to contain a function's | |
1845 | definition using @code{locate-library}; if that finds no file, they | |
1846 | expand the definition file name relative to the directory of the file | |
1847 | that contains the @code{declare-function} call. | |
1848 | ||
735cc5ca CY |
1849 | You can also say that a function is a primitive by specifying a file |
1850 | name ending in @samp{.c} or @samp{.m}. This is useful only when you | |
1851 | call a primitive that is defined only on certain systems. Most | |
1852 | primitives are always defined, so they will never give you a warning. | |
e31dfb12 | 1853 | |
c4540067 GM |
1854 | Sometimes a file will optionally use functions from an external package. |
1855 | If you prefix the filename in the @code{declare-function} statement with | |
1856 | @samp{ext:}, then it will be checked if it is found, otherwise skipped | |
1857 | without error. | |
1858 | ||
8f4b37d8 | 1859 | There are some function definitions that @samp{check-declare} does not |
1df7defd | 1860 | understand (e.g., @code{defstruct} and some other macros). In such cases, |
6297397b GM |
1861 | you can pass a non-@code{nil} @var{fileonly} argument to |
1862 | @code{declare-function}, meaning to only check that the file exists, not | |
1863 | that it actually defines the function. Note that to do this without | |
1864 | having to specify an argument list, you should set the @var{arglist} | |
1865 | argument to @code{t} (because @code{nil} means an empty argument list, as | |
1866 | opposed to an unspecified one). | |
8f4b37d8 | 1867 | |
b8d4c8d0 GM |
1868 | @node Function Safety |
1869 | @section Determining whether a Function is Safe to Call | |
1870 | @cindex function safety | |
1871 | @cindex safety of functions | |
1872 | ||
26026637 | 1873 | Some major modes, such as SES, call functions that are stored in user |
1df7defd | 1874 | files. (@inforef{Top, ,ses}, for more information on SES@.) User |
b8d4c8d0 GM |
1875 | files sometimes have poor pedigrees---you can get a spreadsheet from |
1876 | someone you've just met, or you can get one through email from someone | |
1877 | you've never met. So it is risky to call a function whose source code | |
1878 | is stored in a user file until you have determined that it is safe. | |
1879 | ||
1880 | @defun unsafep form &optional unsafep-vars | |
1881 | Returns @code{nil} if @var{form} is a @dfn{safe} Lisp expression, or | |
1882 | returns a list that describes why it might be unsafe. The argument | |
1883 | @var{unsafep-vars} is a list of symbols known to have temporary | |
1884 | bindings at this point; it is mainly used for internal recursive | |
1885 | calls. The current buffer is an implicit argument, which provides a | |
1886 | list of buffer-local bindings. | |
1887 | @end defun | |
1888 | ||
1889 | Being quick and simple, @code{unsafep} does a very light analysis and | |
1890 | rejects many Lisp expressions that are actually safe. There are no | |
1891 | known cases where @code{unsafep} returns @code{nil} for an unsafe | |
1892 | expression. However, a ``safe'' Lisp expression can return a string | |
1893 | with a @code{display} property, containing an associated Lisp | |
1894 | expression to be executed after the string is inserted into a buffer. | |
1895 | This associated expression can be a virus. In order to be safe, you | |
1896 | must delete properties from all strings calculated by user code before | |
1897 | inserting them into buffers. | |
1898 | ||
1899 | @ignore | |
1900 | What is a safe Lisp expression? Basically, it's an expression that | |
1901 | calls only built-in functions with no side effects (or only innocuous | |
1902 | ones). Innocuous side effects include displaying messages and | |
1903 | altering non-risky buffer-local variables (but not global variables). | |
1904 | ||
1905 | @table @dfn | |
1906 | @item Safe expression | |
1907 | @itemize | |
1908 | @item | |
1909 | An atom or quoted thing. | |
1910 | @item | |
1911 | A call to a safe function (see below), if all its arguments are | |
1912 | safe expressions. | |
1913 | @item | |
1914 | One of the special forms @code{and}, @code{catch}, @code{cond}, | |
1915 | @code{if}, @code{or}, @code{prog1}, @code{prog2}, @code{progn}, | |
1916 | @code{while}, and @code{unwind-protect}], if all its arguments are | |
1917 | safe. | |
1918 | @item | |
1919 | A form that creates temporary bindings (@code{condition-case}, | |
1920 | @code{dolist}, @code{dotimes}, @code{lambda}, @code{let}, or | |
1921 | @code{let*}), if all args are safe and the symbols to be bound are not | |
1922 | explicitly risky (see @pxref{File Local Variables}). | |
1923 | @item | |
1924 | An assignment using @code{add-to-list}, @code{setq}, @code{push}, or | |
1925 | @code{pop}, if all args are safe and the symbols to be assigned are | |
1926 | not explicitly risky and they already have temporary or buffer-local | |
1927 | bindings. | |
1928 | @item | |
1929 | One of [apply, mapc, mapcar, mapconcat] if the first argument is a | |
1930 | safe explicit lambda and the other args are safe expressions. | |
1931 | @end itemize | |
1932 | ||
1933 | @item Safe function | |
1934 | @itemize | |
1935 | @item | |
1936 | A lambda containing safe expressions. | |
1937 | @item | |
1938 | A symbol on the list @code{safe-functions}, so the user says it's safe. | |
1939 | @item | |
1940 | A symbol with a non-@code{nil} @code{side-effect-free} property. | |
1941 | @item | |
27610f35 RS |
1942 | A symbol with a non-@code{nil} @code{safe-function} property. The |
1943 | value @code{t} indicates a function that is safe but has innocuous | |
1944 | side effects. Other values will someday indicate functions with | |
1945 | classes of side effects that are not always safe. | |
b8d4c8d0 GM |
1946 | @end itemize |
1947 | ||
1948 | The @code{side-effect-free} and @code{safe-function} properties are | |
1949 | provided for built-in functions and for low-level functions and macros | |
1950 | defined in @file{subr.el}. You can assign these properties for the | |
1951 | functions you write. | |
1952 | @end table | |
1953 | @end ignore | |
1954 | ||
1955 | @node Related Topics | |
1956 | @section Other Topics Related to Functions | |
1957 | ||
1958 | Here is a table of several functions that do things related to | |
1959 | function calling and function definitions. They are documented | |
1960 | elsewhere, but we provide cross references here. | |
1961 | ||
1962 | @table @code | |
1963 | @item apply | |
1964 | See @ref{Calling Functions}. | |
1965 | ||
1966 | @item autoload | |
1967 | See @ref{Autoload}. | |
1968 | ||
1969 | @item call-interactively | |
1970 | See @ref{Interactive Call}. | |
1971 | ||
39dc0d57 RS |
1972 | @item called-interactively-p |
1973 | See @ref{Distinguish Interactive}. | |
1974 | ||
b8d4c8d0 GM |
1975 | @item commandp |
1976 | See @ref{Interactive Call}. | |
1977 | ||
1978 | @item documentation | |
1979 | See @ref{Accessing Documentation}. | |
1980 | ||
1981 | @item eval | |
1982 | See @ref{Eval}. | |
1983 | ||
1984 | @item funcall | |
1985 | See @ref{Calling Functions}. | |
1986 | ||
1987 | @item function | |
1988 | See @ref{Anonymous Functions}. | |
1989 | ||
1990 | @item ignore | |
1991 | See @ref{Calling Functions}. | |
1992 | ||
1993 | @item indirect-function | |
1994 | See @ref{Function Indirection}. | |
1995 | ||
1996 | @item interactive | |
1997 | See @ref{Using Interactive}. | |
1998 | ||
1999 | @item interactive-p | |
39dc0d57 | 2000 | See @ref{Distinguish Interactive}. |
b8d4c8d0 GM |
2001 | |
2002 | @item mapatoms | |
2003 | See @ref{Creating Symbols}. | |
2004 | ||
2005 | @item mapcar | |
2006 | See @ref{Mapping Functions}. | |
2007 | ||
2008 | @item map-char-table | |
2009 | See @ref{Char-Tables}. | |
2010 | ||
2011 | @item mapconcat | |
2012 | See @ref{Mapping Functions}. | |
2013 | ||
2014 | @item undefined | |
2015 | See @ref{Functions for Key Lookup}. | |
2016 | @end table |