diff options
| author | Richard M. Stallman | 2005-02-14 10:11:48 +0000 |
|---|---|---|
| committer | Richard M. Stallman | 2005-02-14 10:11:48 +0000 |
| commit | 67bce69d3891bd210040baf8149b7f305f16c3f2 (patch) | |
| tree | 878f737c000973ab6a31bb104c6b6bd429e0a779 | |
| parent | 85831f9a60cca17cfe2fc201667c599091e9cc50 (diff) | |
| download | emacs-67bce69d3891bd210040baf8149b7f305f16c3f2.tar.gz emacs-67bce69d3891bd210040baf8149b7f305f16c3f2.zip | |
(What Is a Function): Wording cleanup.
(Function Documentation): Minor cleanup.
Explain purpose of calling convention at end of doc string.
(Function Names): Wording cleanup.
(Calling Functions): Wording cleanup.
Explain better how funcall calls the function.
(Function Cells): Delete example of saving and redefining function.
| -rw-r--r-- | lispref/functions.texi | 86 |
1 files changed, 37 insertions, 49 deletions
diff --git a/lispref/functions.texi b/lispref/functions.texi index 5c7433507b0..26c2449fee6 100644 --- a/lispref/functions.texi +++ b/lispref/functions.texi | |||
| @@ -53,7 +53,7 @@ macros are not functions. | |||
| 53 | @cindex built-in function | 53 | @cindex built-in function |
| 54 | A @dfn{primitive} is a function callable from Lisp that is written in C, | 54 | A @dfn{primitive} is a function callable from Lisp that is written in C, |
| 55 | such as @code{car} or @code{append}. These functions are also called | 55 | such as @code{car} or @code{append}. These functions are also called |
| 56 | @dfn{built-in} functions or @dfn{subrs}. (Special forms are also | 56 | @dfn{built-in functions}, or @dfn{subrs}. (Special forms are also |
| 57 | considered primitives.) | 57 | considered primitives.) |
| 58 | 58 | ||
| 59 | Usually the reason we implement a function as a primitive is either | 59 | Usually the reason we implement a function as a primitive is either |
| @@ -412,13 +412,14 @@ are easier to access. | |||
| 412 | because @code{apropos} displays just this first line. It should consist | 412 | because @code{apropos} displays just this first line. It should consist |
| 413 | of one or two complete sentences that summarize the function's purpose. | 413 | of one or two complete sentences that summarize the function's purpose. |
| 414 | 414 | ||
| 415 | The start of the documentation string is usually indented in the source file, | 415 | The start of the documentation string is usually indented in the |
| 416 | but since these spaces come before the starting double-quote, they are not part of | 416 | source file, but since these spaces come before the starting |
| 417 | the string. Some people make a practice of indenting any additional | 417 | double-quote, they are not part of the string. Some people make a |
| 418 | lines of the string so that the text lines up in the program source. | 418 | practice of indenting any additional lines of the string so that the |
| 419 | @emph{That is a mistake.} The indentation of the following lines is | 419 | text lines up in the program source. @emph{That is a mistake.} The |
| 420 | inside the string; what looks nice in the source code will look ugly | 420 | indentation of the following lines is inside the string; what looks |
| 421 | when displayed by the help commands. | 421 | nice in the source code will look ugly when displayed by the help |
| 422 | commands. | ||
| 422 | 423 | ||
| 423 | You may wonder how the documentation string could be optional, since | 424 | You may wonder how the documentation string could be optional, since |
| 424 | there are required components of the function that follow it (the body). | 425 | there are required components of the function that follow it (the body). |
| @@ -438,9 +439,14 @@ text like this: | |||
| 438 | 439 | ||
| 439 | @noindent | 440 | @noindent |
| 440 | following a blank line, at the beginning of the line, with no newline | 441 | following a blank line, at the beginning of the line, with no newline |
| 441 | following it inside the documentation string. This feature is | 442 | following it inside the documentation string. (The @samp{\} is used |
| 442 | particularly useful for macro definitions. The @samp{\} is used to | 443 | to avoid confusing the Emacs motion commands.) The calling convention |
| 443 | avoid confusing the Emacs motion commands. | 444 | specified in this way appears in help messages in place of the one |
| 445 | derived from the actual arguments of the function. | ||
| 446 | |||
| 447 | This feature is particularly useful for macro definitions, since the | ||
| 448 | arguments written in a macro definition often do not correspond to the | ||
| 449 | way users think of the parts of the macro call. | ||
| 444 | 450 | ||
| 445 | @node Function Names | 451 | @node Function Names |
| 446 | @section Naming a Function | 452 | @section Naming a Function |
| @@ -481,8 +487,8 @@ practice). | |||
| 481 | We often identify functions with the symbols used to name them. For | 487 | We often identify functions with the symbols used to name them. For |
| 482 | example, we often speak of ``the function @code{car}'', not | 488 | example, we often speak of ``the function @code{car}'', not |
| 483 | distinguishing between the symbol @code{car} and the primitive | 489 | distinguishing between the symbol @code{car} and the primitive |
| 484 | subr-object that is its function definition. For most purposes, there | 490 | subr-object that is its function definition. For most purposes, the |
| 485 | is no need to distinguish. | 491 | distinction is not important. |
| 486 | 492 | ||
| 487 | Even so, keep in mind that a function need not have a unique name. While | 493 | Even so, keep in mind that a function need not have a unique name. While |
| 488 | a given function object @emph{usually} appears in the function cell of only | 494 | a given function object @emph{usually} appears in the function cell of only |
| @@ -626,13 +632,12 @@ For example, evaluating the list @code{(concat "a" "b")} calls the | |||
| 626 | function @code{concat} with arguments @code{"a"} and @code{"b"}. | 632 | function @code{concat} with arguments @code{"a"} and @code{"b"}. |
| 627 | @xref{Evaluation}, for a description of evaluation. | 633 | @xref{Evaluation}, for a description of evaluation. |
| 628 | 634 | ||
| 629 | When you write a list as an expression in your program, the function | 635 | When you write a list as an expression in your program, you specify |
| 630 | name it calls is written in your program. This means that you choose | 636 | which function to call, and how many arguments to give it, in the text |
| 631 | which function to call, and how many arguments to give it, when you | 637 | of the program. Usually that's just what you want. Occasionally you |
| 632 | write the program. Usually that's just what you want. Occasionally you | 638 | need to compute at run time which function to call. To do that, use |
| 633 | need to compute at run time which function to call. To do that, use the | 639 | the function @code{funcall}. When you also need to determine at run |
| 634 | function @code{funcall}. When you also need to determine at run time | 640 | time how many arguments to pass, use @code{apply}. |
| 635 | how many arguments to pass, use @code{apply}. | ||
| 636 | 641 | ||
| 637 | @defun funcall function &rest arguments | 642 | @defun funcall function &rest arguments |
| 638 | @code{funcall} calls @var{function} with @var{arguments}, and returns | 643 | @code{funcall} calls @var{function} with @var{arguments}, and returns |
| @@ -641,11 +646,12 @@ whatever @var{function} returns. | |||
| 641 | Since @code{funcall} is a function, all of its arguments, including | 646 | Since @code{funcall} is a function, all of its arguments, including |
| 642 | @var{function}, are evaluated before @code{funcall} is called. This | 647 | @var{function}, are evaluated before @code{funcall} is called. This |
| 643 | means that you can use any expression to obtain the function to be | 648 | means that you can use any expression to obtain the function to be |
| 644 | called. It also means that @code{funcall} does not see the expressions | 649 | called. It also means that @code{funcall} does not see the |
| 645 | you write for the @var{arguments}, only their values. These values are | 650 | expressions you write for the @var{arguments}, only their values. |
| 646 | @emph{not} evaluated a second time in the act of calling @var{function}; | 651 | These values are @emph{not} evaluated a second time in the act of |
| 647 | @code{funcall} enters the normal procedure for calling a function at the | 652 | calling @var{function}; the operation of @code{funcall} is like the |
| 648 | place where the arguments have already been evaluated. | 653 | normal procedure for calling a function, once its arguments have |
| 654 | already been evaluated. | ||
| 649 | 655 | ||
| 650 | The argument @var{function} must be either a Lisp function or a | 656 | The argument @var{function} must be either a Lisp function or a |
| 651 | primitive function. Special forms and macros are not allowed, because | 657 | primitive function. Special forms and macros are not allowed, because |
| @@ -1137,30 +1143,12 @@ Here are examples of these uses: | |||
| 1137 | @end example | 1143 | @end example |
| 1138 | @end defun | 1144 | @end defun |
| 1139 | 1145 | ||
| 1140 | When writing a function that extends a previously defined function, | 1146 | @code{fset} is sometimes used to save the old definition of a |
| 1141 | the following idiom is sometimes used: | 1147 | function before redefining it. That permits the new definition to |
| 1142 | 1148 | invoke the old definition. But it is unmodular and unclean for a Lisp | |
| 1143 | @example | 1149 | file to redefine a function defined elsewhere. If you want to modify |
| 1144 | (fset 'old-foo (symbol-function 'foo)) | 1150 | a function defined by another package, it is cleaner to use |
| 1145 | (defun foo () | 1151 | @code{defadvice} (@pxref{Advising Functions}). |
| 1146 | "Just like old-foo, except more so." | ||
| 1147 | @group | ||
| 1148 | (old-foo) | ||
| 1149 | (more-so)) | ||
| 1150 | @end group | ||
| 1151 | @end example | ||
| 1152 | |||
| 1153 | @noindent | ||
| 1154 | This does not work properly if @code{foo} has been defined to autoload. | ||
| 1155 | In such a case, when @code{foo} calls @code{old-foo}, Lisp attempts | ||
| 1156 | to define @code{old-foo} by loading a file. Since this presumably | ||
| 1157 | defines @code{foo} rather than @code{old-foo}, it does not produce the | ||
| 1158 | proper results. The only way to avoid this problem is to make sure the | ||
| 1159 | file is loaded before moving aside the old definition of @code{foo}. | ||
| 1160 | |||
| 1161 | But it is unmodular and unclean, in any case, for a Lisp file to | ||
| 1162 | redefine a function defined elsewhere. It is cleaner to use the advice | ||
| 1163 | facility (@pxref{Advising Functions}). | ||
| 1164 | 1152 | ||
| 1165 | @node Inline Functions | 1153 | @node Inline Functions |
| 1166 | @section Inline Functions | 1154 | @section Inline Functions |