@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual.
-@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2004
-@c Free Software Foundation, Inc.
+@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2002, 2003,
+@c 2004, 2005, 2006 Free Software Foundation, Inc.
@c See the file elisp.texi for copying conditions.
@setfilename ../info/functions
@node Functions, Macros, Variables, Top
* Anonymous Functions:: Lambda expressions are functions with no names.
* Function Cells:: Accessing or setting the function definition
of a symbol.
+* Obsolete Functions:: Declaring functions obsolete.
* Inline Functions:: Defining functions that the compiler will open code.
* Function Safety:: Determining whether a function is safe to call.
* Related Topics:: Cross-references to specific Lisp primitives
@cindex built-in function
A @dfn{primitive} is a function callable from Lisp that is written in C,
such as @code{car} or @code{append}. These functions are also called
-@dfn{built-in} functions or @dfn{subrs}. (Special forms are also
+@dfn{built-in functions}, or @dfn{subrs}. (Special forms are also
considered primitives.)
Usually the reason we implement a function as a primitive is either
they are not functions. A symbol is a command if its function
definition is a command; such symbols can be invoked with @kbd{M-x}.
The symbol is a function as well if the definition is a function.
-@xref{Command Overview}.
+@xref{Interactive Call}.
@item keystroke command
@cindex keystroke command
because @code{apropos} displays just this first line. It should consist
of one or two complete sentences that summarize the function's purpose.
- The start of the documentation string is usually indented in the source file,
-but since these spaces come before the starting double-quote, they are not part of
-the string. Some people make a practice of indenting any additional
-lines of the string so that the text lines up in the program source.
-@emph{That is a mistake.} The indentation of the following lines is
-inside the string; what looks nice in the source code will look ugly
-when displayed by the help commands.
+ The start of the documentation string is usually indented in the
+source file, but since these spaces come before the starting
+double-quote, they are not part of the string. Some people make a
+practice of indenting any additional lines of the string so that the
+text lines up in the program source. @emph{That is a mistake.} The
+indentation of the following lines is inside the string; what looks
+nice in the source code will look ugly when displayed by the help
+commands.
You may wonder how the documentation string could be optional, since
there are required components of the function that follow it (the body).
@noindent
following a blank line, at the beginning of the line, with no newline
-following it inside the documentation string. This feature is
-particularly useful for macro definitions. The @samp{\} is used to
-avoid confusing the Emacs motion commands.
+following it inside the documentation string. (The @samp{\} is used
+to avoid confusing the Emacs motion commands.) The calling convention
+specified in this way appears in help messages in place of the one
+derived from the actual arguments of the function.
+
+ This feature is particularly useful for macro definitions, since the
+arguments written in a macro definition often do not correspond to the
+way users think of the parts of the macro call.
@node Function Names
@section Naming a Function
We often identify functions with the symbols used to name them. For
example, we often speak of ``the function @code{car}'', not
distinguishing between the symbol @code{car} and the primitive
-subr-object that is its function definition. For most purposes, there
-is no need to distinguish.
+subr-object that is its function definition. For most purposes, the
+distinction is not important.
Even so, keep in mind that a function need not have a unique name. While
a given function object @emph{usually} appears in the function cell of only
@var{name}. It returns the value @var{name}, but usually we ignore this
value.
-As described previously (@pxref{Lambda Expressions}),
-@var{argument-list} is a list of argument names and may include the
-keywords @code{&optional} and @code{&rest}. Also, the first two of the
+As described previously, @var{argument-list} is a list of argument
+names and may include the keywords @code{&optional} and @code{&rest}
+(@pxref{Lambda Expressions}). Also, the first two of the
@var{body-forms} may be a documentation string and an interactive
declaration.
By contrast, in programs that manipulate function definitions for other
purposes, it is better to use @code{fset}, which does not keep such
-records.
+records. @xref{Function Cells}.
@end defun
You cannot create a new primitive function with @code{defun} or
function @code{concat} with arguments @code{"a"} and @code{"b"}.
@xref{Evaluation}, for a description of evaluation.
- When you write a list as an expression in your program, the function
-name it calls is written in your program. This means that you choose
-which function to call, and how many arguments to give it, when you
-write the program. Usually that's just what you want. Occasionally you
-need to compute at run time which function to call. To do that, use the
-function @code{funcall}. When you also need to determine at run time
-how many arguments to pass, use @code{apply}.
+ When you write a list as an expression in your program, you specify
+which function to call, and how many arguments to give it, in the text
+of the program. Usually that's just what you want. Occasionally you
+need to compute at run time which function to call. To do that, use
+the function @code{funcall}. When you also need to determine at run
+time how many arguments to pass, use @code{apply}.
@defun funcall function &rest arguments
@code{funcall} calls @var{function} with @var{arguments}, and returns
Since @code{funcall} is a function, all of its arguments, including
@var{function}, are evaluated before @code{funcall} is called. This
means that you can use any expression to obtain the function to be
-called. It also means that @code{funcall} does not see the expressions
-you write for the @var{arguments}, only their values. These values are
-@emph{not} evaluated a second time in the act of calling @var{function};
-@code{funcall} enters the normal procedure for calling a function at the
-place where the arguments have already been evaluated.
+called. It also means that @code{funcall} does not see the
+expressions you write for the @var{arguments}, only their values.
+These values are @emph{not} evaluated a second time in the act of
+calling @var{function}; the operation of @code{funcall} is like the
+normal procedure for calling a function, once its arguments have
+already been evaluated.
The argument @var{function} must be either a Lisp function or a
primitive function. Special forms and macros are not allowed, because
@end example
@end defun
- When writing a function that extends a previously defined function,
-the following idiom is sometimes used:
+ @code{fset} is sometimes used to save the old definition of a
+function before redefining it. That permits the new definition to
+invoke the old definition. But it is unmodular and unclean for a Lisp
+file to redefine a function defined elsewhere. If you want to modify
+a function defined by another package, it is cleaner to use
+@code{defadvice} (@pxref{Advising Functions}).
+
+@node Obsolete Functions
+@section Declaring Functions Obsolete
+
+You can use @code{make-obsolete} to declare a function obsolete. This
+indicates that the function may be removed at some stage in the future.
+
+@defun make-obsolete obsolete-name current-name &optional when
+This function makes the byte compiler warn that the function
+@var{obsolete-name} is obsolete. If @var{current-name} is a symbol, the
+warning message says to use @var{current-name} instead of
+@var{obsolete-name}. @var{current-name} does not need to be an alias for
+@var{obsolete-name}; it can be a different function with similar
+functionality. If @var{current-name} is a string, it is the warning
+message.
+
+If provided, @var{when} should be a string indicating when the function
+was first made obsolete---for example, a date or a release number.
+@end defun
-@example
-(fset 'old-foo (symbol-function 'foo))
-(defun foo ()
- "Just like old-foo, except more so."
-@group
- (old-foo)
- (more-so))
-@end group
-@end example
+You can define a function as an alias and declare it obsolete at the
+same time using the macro @code{define-obsolete-function-alias}.
-@noindent
-This does not work properly if @code{foo} has been defined to autoload.
-In such a case, when @code{foo} calls @code{old-foo}, Lisp attempts
-to define @code{old-foo} by loading a file. Since this presumably
-defines @code{foo} rather than @code{old-foo}, it does not produce the
-proper results. The only way to avoid this problem is to make sure the
-file is loaded before moving aside the old definition of @code{foo}.
+@defmac define-obsolete-function-alias obsolete-name current-name &optional when docstring
+This macro marks the function @var{obsolete-name} obsolete and also
+defines it as an alias for the function @var{current-name}. It is
+equivalent to the following:
- But it is unmodular and unclean, in any case, for a Lisp file to
-redefine a function defined elsewhere. It is cleaner to use the advice
-facility (@pxref{Advising Functions}).
+@example
+(defalias @var{obsolete-name} @var{current-name} @var{docstring})
+(make-obsolete @var{obsolete-name} @var{current-name} @var{when})
+@end example
+@end defmac
@node Inline Functions
@section Inline Functions
following the definition, just like macros.
@node Function Safety
-@section Determining whether a function is safe to call
+@section Determining whether a Function is Safe to Call
@cindex function safety
@cindex safety of functions