[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to functions.texi
|
From: |
Glenn Morris |
|
Subject: |
[Emacs-diffs] Changes to functions.texi |
|
Date: |
Thu, 06 Sep 2007 04:20:17 +0000 |
CVSROOT: /sources/emacs
Module name: emacs
Changes by: Glenn Morris <gm> 07/09/06 04:20:16
Index: functions.texi
===================================================================
RCS file: functions.texi
diff -N functions.texi
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ functions.texi 6 Sep 2007 04:20:16 -0000 1.1
@@ -0,0 +1,1374 @@
address@hidden -*-texinfo-*-
address@hidden This is part of the GNU Emacs Lisp Reference Manual.
address@hidden Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999,
2001,
address@hidden 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation,
Inc.
address@hidden See the file elisp.texi for copying conditions.
address@hidden ../info/functions
address@hidden Functions, Macros, Variables, Top
address@hidden Functions
+
+ A Lisp program is composed mainly of Lisp functions. This chapter
+explains what functions are, how they accept arguments, and how to
+define them.
+
address@hidden
+* What Is a Function:: Lisp functions vs. primitives; terminology.
+* Lambda Expressions:: How functions are expressed as Lisp objects.
+* Function Names:: A symbol can serve as the name of a function.
+* Defining Functions:: Lisp expressions for defining functions.
+* Calling Functions:: How to use an existing function.
+* Mapping Functions:: Applying a function to each element of a list, etc.
+* 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
+ that have a special bearing on how functions work.
address@hidden menu
+
address@hidden What Is a Function
address@hidden What Is a Function?
+
+ In a general sense, a function is a rule for carrying on a computation
+given several values called @dfn{arguments}. The result of the
+computation is called the value of the function. The computation can
+also have side effects: lasting changes in the values of variables or
+the contents of data structures.
+
+ Here are important terms for functions in Emacs Lisp and for other
+function-like objects.
+
address@hidden @dfn
address@hidden function
address@hidden function
+In Emacs Lisp, a @dfn{function} is anything that can be applied to
+arguments in a Lisp program. In some cases, we use it more
+specifically to mean a function written in Lisp. Special forms and
+macros are not functions.
+
address@hidden primitive
address@hidden primitive
address@hidden subr
address@hidden 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
address@hidden functions}, or @dfn{subrs}. (Special forms are also
+considered primitives.)
+
+Usually the reason we implement a function as a primitive is either
+because it is fundamental, because it provides a low-level interface
+to operating system services, or because it needs to run fast.
+Primitives can be modified or added only by changing the C sources and
+recompiling the editor. See @ref{Writing Emacs Primitives}.
+
address@hidden lambda expression
+A @dfn{lambda expression} is a function written in Lisp.
+These are described in the following section.
address@hidden
address@hidden Expressions}.
address@hidden ifnottex
+
address@hidden special form
+A @dfn{special form} is a primitive that is like a function but does not
+evaluate all of its arguments in the usual way. It may evaluate only
+some of the arguments, or may evaluate them in an unusual order, or
+several times. Many special forms are described in @ref{Control
+Structures}.
+
address@hidden macro
address@hidden macro
+A @dfn{macro} is a construct defined in Lisp by the programmer. It
+differs from a function in that it translates a Lisp expression that you
+write into an equivalent expression to be evaluated instead of the
+original expression. Macros enable Lisp programmers to do the sorts of
+things that special forms can do. @xref{Macros}, for how to define and
+use macros.
+
address@hidden command
address@hidden command
+A @dfn{command} is an object that @code{command-execute} can invoke; it
+is a possible definition for a key sequence. Some functions are
+commands; a function written in Lisp is a command if it contains an
+interactive declaration (@pxref{Defining Commands}). Such a function
+can be called from Lisp expressions like other functions; in this case,
+the fact that the function is a command makes no difference.
+
+Keyboard macros (strings and vectors) are commands also, even though
+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.
address@hidden Call}.
+
address@hidden keystroke command
address@hidden keystroke command
+A @dfn{keystroke command} is a command that is bound to a key sequence
+(typically one to three keystrokes). The distinction is made here
+merely to avoid confusion with the meaning of ``command'' in non-Emacs
+editors; for Lisp programs, the distinction is normally unimportant.
+
address@hidden byte-code function
+A @dfn{byte-code function} is a function that has been compiled by the
+byte compiler. @xref{Byte-Code Type}.
address@hidden table
+
address@hidden functionp object
+This function returns @code{t} if @var{object} is any kind of
+function, or a special form, or, recursively, a symbol whose function
+definition is a function or special form. (This does not include
+macros.)
address@hidden defun
+
+Unlike @code{functionp}, the next three functions do @emph{not}
+treat a symbol as its function definition.
+
address@hidden subrp object
+This function returns @code{t} if @var{object} is a built-in function
+(i.e., a Lisp primitive).
+
address@hidden
address@hidden
+(subrp 'message) ; @address@hidden is a symbol,}
+ @result{} nil ; @r{not a subr object.}
address@hidden group
address@hidden
+(subrp (symbol-function 'message))
+ @result{} t
address@hidden group
address@hidden example
address@hidden defun
+
address@hidden byte-code-function-p object
+This function returns @code{t} if @var{object} is a byte-code
+function. For example:
+
address@hidden
address@hidden
+(byte-code-function-p (symbol-function 'next-line))
+ @result{} t
address@hidden group
address@hidden example
address@hidden defun
+
address@hidden subr-arity subr
+This function provides information about the argument list of a
+primitive, @var{subr}. The returned value is a pair
address@hidden(@var{min} . @var{max})}. @var{min} is the minimum number of
+args. @var{max} is the maximum number or the symbol @code{many}, for a
+function with @code{&rest} arguments, or the symbol @code{unevalled} if
address@hidden is a special form.
address@hidden defun
+
address@hidden Lambda Expressions
address@hidden Lambda Expressions
address@hidden lambda expression
+
+ A function written in Lisp is a list that looks like this:
+
address@hidden
+(lambda (@address@hidden)
+ @address@hidden@r{]}
+ @address@hidden@r{]}
+ @address@hidden)
address@hidden example
+
address@hidden
+Such a list is called a @dfn{lambda expression}. In Emacs Lisp, it
+actually is valid as an expression---it evaluates to itself. In some
+other Lisp dialects, a lambda expression is not a valid expression at
+all. In either case, its main use is not to be evaluated as an
+expression, but to be called as a function.
+
address@hidden
+* Lambda Components:: The parts of a lambda expression.
+* Simple Lambda:: A simple example.
+* Argument List:: Details and special features of argument lists.
+* Function Documentation:: How to put documentation in a function.
address@hidden menu
+
address@hidden Lambda Components
address@hidden Components of a Lambda Expression
+
address@hidden
+
+ A function written in Lisp (a ``lambda expression'') is a list that
+looks like this:
+
address@hidden
+(lambda (@address@hidden)
+ address@hidden
+ address@hidden
+ @address@hidden)
address@hidden example
address@hidden ifnottex
+
address@hidden lambda list
+ The first element of a lambda expression is always the symbol
address@hidden This indicates that the list represents a function. The
+reason functions are defined to start with @code{lambda} is so that
+other lists, intended for other uses, will not accidentally be valid as
+functions.
+
+ The second element is a list of symbols---the argument variable names.
+This is called the @dfn{lambda list}. When a Lisp function is called,
+the argument values are matched up against the variables in the lambda
+list, which are given local bindings with the values provided.
address@hidden Variables}.
+
+ The documentation string is a Lisp string object placed within the
+function definition to describe the function for the Emacs help
+facilities. @xref{Function Documentation}.
+
+ The interactive declaration is a list of the form @code{(interactive
address@hidden)}. This declares how to provide arguments if the
+function is used interactively. Functions with this declaration are called
address@hidden; they can be called using @kbd{M-x} or bound to a key.
+Functions not intended to be called in this way should not have interactive
+declarations. @xref{Defining Commands}, for how to write an interactive
+declaration.
+
address@hidden body of function
+ The rest of the elements are the @dfn{body} of the function: the Lisp
+code to do the work of the function (or, as a Lisp programmer would say,
+``a list of Lisp forms to evaluate''). The value returned by the
+function is the value returned by the last element of the body.
+
address@hidden Simple Lambda
address@hidden A Simple Lambda-Expression Example
+
+ Consider for example the following function:
+
address@hidden
+(lambda (a b c) (+ a b c))
address@hidden example
+
address@hidden
+We can call this function by writing it as the @sc{car} of an
+expression, like this:
+
address@hidden
address@hidden
+((lambda (a b c) (+ a b c))
+ 1 2 3)
address@hidden group
address@hidden example
+
address@hidden
+This call evaluates the body of the lambda expression with the variable
address@hidden bound to 1, @code{b} bound to 2, and @code{c} bound to 3.
+Evaluation of the body adds these three numbers, producing the result 6;
+therefore, this call to the function returns the value 6.
+
+ Note that the arguments can be the results of other function calls, as in
+this example:
+
address@hidden
address@hidden
+((lambda (a b c) (+ a b c))
+ 1 (* 2 3) (- 5 4))
address@hidden group
address@hidden example
+
address@hidden
+This evaluates the arguments @code{1}, @code{(* 2 3)}, and @code{(- 5
+4)} from left to right. Then it applies the lambda expression to the
+argument values 1, 6 and 1 to produce the value 8.
+
+ It is not often useful to write a lambda expression as the @sc{car} of
+a form in this way. You can get the same result, of making local
+variables and giving them values, using the special form @code{let}
+(@pxref{Local Variables}). And @code{let} is clearer and easier to use.
+In practice, lambda expressions are either stored as the function
+definitions of symbols, to produce named functions, or passed as
+arguments to other functions (@pxref{Anonymous Functions}).
+
+ However, calls to explicit lambda expressions were very useful in the
+old days of Lisp, before the special form @code{let} was invented. At
+that time, they were the only way to bind and initialize local
+variables.
+
address@hidden Argument List
address@hidden Other Features of Argument Lists
address@hidden wrong-number-of-arguments
address@hidden argument binding
address@hidden binding arguments
address@hidden argument lists, features
+
+ Our simple sample function, @code{(lambda (a b c) (+ a b c))},
+specifies three argument variables, so it must be called with three
+arguments: if you try to call it with only two arguments or four
+arguments, you get a @code{wrong-number-of-arguments} error.
+
+ It is often convenient to write a function that allows certain
+arguments to be omitted. For example, the function @code{substring}
+accepts three arguments---a string, the start index and the end
+index---but the third argument defaults to the @var{length} of the
+string if you omit it. It is also convenient for certain functions to
+accept an indefinite number of arguments, as the functions @code{list}
+and @code{+} do.
+
address@hidden optional arguments
address@hidden rest arguments
address@hidden &optional
address@hidden &rest
+ To specify optional arguments that may be omitted when a function
+is called, simply include the keyword @code{&optional} before the optional
+arguments. To specify a list of zero or more extra arguments, include the
+keyword @code{&rest} before one final argument.
+
+ Thus, the complete syntax for an argument list is as follows:
+
address@hidden
address@hidden
+(@address@hidden
+ @r{[}&optional @address@hidden@r{]}
+ @r{[}&rest @address@hidden)
address@hidden group
address@hidden example
+
address@hidden
+The square brackets indicate that the @code{&optional} and @code{&rest}
+clauses, and the variables that follow them, are optional.
+
+ A call to the function requires one actual argument for each of the
address@hidden There may be actual arguments for zero or more of
+the @var{optional-vars}, and there cannot be any actual arguments beyond
+that unless the lambda list uses @code{&rest}. In that case, there may
+be any number of extra actual arguments.
+
+ If actual arguments for the optional and rest variables are omitted,
+then they always default to @code{nil}. There is no way for the
+function to distinguish between an explicit argument of @code{nil} and
+an omitted argument. However, the body of the function is free to
+consider @code{nil} an abbreviation for some other meaningful value.
+This is what @code{substring} does; @code{nil} as the third argument to
address@hidden means to use the length of the string supplied.
+
address@hidden CL note---default optional arg
address@hidden
address@hidden Lisp note:} Common Lisp allows the function to specify what
+default value to use when an optional argument is omitted; Emacs Lisp
+always uses @code{nil}. Emacs Lisp does not support ``supplied-p''
+variables that tell you whether an argument was explicitly passed.
address@hidden quotation
+
+ For example, an argument list that looks like this:
+
address@hidden
+(a b &optional c d &rest e)
address@hidden example
+
address@hidden
+binds @code{a} and @code{b} to the first two actual arguments, which are
+required. If one or two more arguments are provided, @code{c} and
address@hidden are bound to them respectively; any arguments after the first
+four are collected into a list and @code{e} is bound to that list. If
+there are only two arguments, @code{c} is @code{nil}; if two or three
+arguments, @code{d} is @code{nil}; if four arguments or fewer, @code{e}
+is @code{nil}.
+
+ There is no way to have required arguments following optional
+ones---it would not make sense. To see why this must be so, suppose
+that @code{c} in the example were optional and @code{d} were required.
+Suppose three actual arguments are given; which variable would the
+third argument be for? Would it be used for the @var{c}, or for
address@hidden One can argue for both possibilities. Similarly, it makes
+no sense to have any more arguments (either required or optional)
+after a @code{&rest} argument.
+
+ Here are some examples of argument lists and proper calls:
+
address@hidden
+((lambda (n) (1+ n)) ; @r{One required:}
+ 1) ; @r{requires exactly one argument.}
+ @result{} 2
+((lambda (n &optional n1) ; @r{One required and one optional:}
+ (if n1 (+ n n1) (1+ n))) ; @r{1 or 2 arguments.}
+ 1 2)
+ @result{} 3
+((lambda (n &rest ns) ; @r{One required and one rest:}
+ (+ n (apply '+ ns))) ; @r{1 or more arguments.}
+ 1 2 3 4 5)
+ @result{} 15
address@hidden smallexample
+
address@hidden Function Documentation
address@hidden Documentation Strings of Functions
address@hidden documentation of function
+
+ A lambda expression may optionally have a @dfn{documentation string} just
+after the lambda list. This string does not affect execution of the
+function; it is a kind of comment, but a systematized comment which
+actually appears inside the Lisp world and can be used by the Emacs help
+facilities. @xref{Documentation}, for how the @var{documentation-string} is
+accessed.
+
+ It is a good idea to provide documentation strings for all the
+functions in your program, even those that are called only from within
+your program. Documentation strings are like comments, except that they
+are easier to access.
+
+ The first line of the documentation string should stand on its own,
+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.
+
+ You may wonder how the documentation string could be optional, since
+there are required components of the function that follow it (the body).
+Since evaluation of a string returns that string, without any side effects,
+it has no effect if it is not the last form in the body. Thus, in
+practice, there is no confusion between the first form of the body and the
+documentation string; if the only body form is a string then it serves both
+as the return value and as the documentation.
+
+ The last line of the documentation string can specify calling
+conventions different from the actual function arguments. Write
+text like this:
+
address@hidden
+\(fn @var{arglist})
address@hidden example
+
address@hidden
+following a blank line, at the beginning of the line, with no newline
+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.
+
address@hidden Function Names
address@hidden Naming a Function
address@hidden function definition
address@hidden named function
address@hidden function name
+
+ In most computer languages, every function has a name; the idea of a
+function without a name is nonsensical. In Lisp, a function in the
+strictest sense has no name. It is simply a list whose first element is
address@hidden, a byte-code function object, or a primitive subr-object.
+
+ However, a symbol can serve as the name of a function. This happens
+when you put the function in the symbol's @dfn{function cell}
+(@pxref{Symbol Components}). Then the symbol itself becomes a valid,
+callable function, equivalent to the list or subr-object that its
+function cell refers to. The contents of the function cell are also
+called the symbol's @dfn{function definition}. The procedure of using a
+symbol's function definition in place of the symbol is called
address@hidden function indirection}; see @ref{Function Indirection}.
+
+ In practice, nearly all functions are given names in this way and
+referred to through their names. For example, the symbol @code{car} works
+as a function and does what it does because the primitive subr-object
address@hidden<subr car>} is stored in its function cell.
+
+ We give functions names because it is convenient to refer to them by
+their names in Lisp expressions. For primitive subr-objects such as
address@hidden<subr car>}, names are the only way you can refer to them: there
+is no read syntax for such objects. For functions written in Lisp, the
+name is more convenient to use in a call than an explicit lambda
+expression. Also, a function with a name can refer to itself---it can
+be recursive. Writing the function's name in its own definition is much
+more convenient than making the function definition point to itself
+(something that is not impossible but that has various disadvantages in
+practice).
+
+ 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, 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
+one symbol, this is just a matter of convenience. It is easy to store
+it in several symbols using @code{fset}; then each of the symbols is
+equally well a name for the same function.
+
+ A symbol used as a function name may also be used as a variable; these
+two uses of a symbol are independent and do not conflict. (Some Lisp
+dialects, such as Scheme, do not distinguish between a symbol's value
+and its function definition; a symbol's value as a variable is also its
+function definition.) If you have not given a symbol a function
+definition, you cannot use it as a function; whether the symbol has a
+value as a variable makes no difference to this.
+
address@hidden Defining Functions
address@hidden Defining Functions
address@hidden defining a function
+
+ We usually give a name to a function when it is first created. This
+is called @dfn{defining a function}, and it is done with the
address@hidden special form.
+
address@hidden defun name argument-list body-forms
address@hidden is the usual way to define new Lisp functions. It
+defines the symbol @var{name} as a function that looks like this:
+
address@hidden
+(lambda @var{argument-list} . @var{body-forms})
address@hidden example
+
address@hidden stores this lambda expression in the function cell of
address@hidden It returns the value @var{name}, but usually we ignore this
+value.
+
+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
address@hidden may be a documentation string and an interactive
+declaration.
+
+There is no conflict if the same symbol @var{name} is also used as a
+variable, since the symbol's value cell is independent of the function
+cell. @xref{Symbol Components}.
+
+Here are some examples:
+
address@hidden
address@hidden
+(defun foo () 5)
+ @result{} foo
address@hidden group
address@hidden
+(foo)
+ @result{} 5
address@hidden group
+
address@hidden
+(defun bar (a &optional b &rest c)
+ (list a b c))
+ @result{} bar
address@hidden group
address@hidden
+(bar 1 2 3 4 5)
+ @result{} (1 2 (3 4 5))
address@hidden group
address@hidden
+(bar 1)
+ @result{} (1 nil nil)
address@hidden group
address@hidden
+(bar)
address@hidden Wrong number of arguments.
address@hidden group
+
address@hidden
+(defun capitalize-backwards ()
+ "Upcase the last letter of a word."
+ (interactive)
+ (backward-word 1)
+ (forward-word 1)
+ (backward-char 1)
+ (capitalize-word 1))
+ @result{} capitalize-backwards
address@hidden group
address@hidden example
+
+Be careful not to redefine existing functions unintentionally.
address@hidden redefines even primitive functions such as @code{car}
+without any hesitation or notification. Redefining a function already
+defined is often done deliberately, and there is no way to distinguish
+deliberate redefinition from unintentional redefinition.
address@hidden defspec
+
address@hidden function aliases
address@hidden defalias name definition &optional docstring
address@hidden of defalias}
+This special form defines the symbol @var{name} as a function, with
+definition @var{definition} (which can be any valid Lisp function).
+It returns @var{definition}.
+
+If @var{docstring} is address@hidden, it becomes the function
+documentation of @var{name}. Otherwise, any documentation provided by
address@hidden is used.
+
+The proper place to use @code{defalias} is where a specific function
+name is being defined---especially where that name appears explicitly in
+the source file being loaded. This is because @code{defalias} records
+which file defined the function, just like @code{defun}
+(@pxref{Unloading}).
+
+By contrast, in programs that manipulate function definitions for other
+purposes, it is better to use @code{fset}, which does not keep such
+records. @xref{Function Cells}.
address@hidden defun
+
+ You cannot create a new primitive function with @code{defun} or
address@hidden, but you can use them to change the function definition of
+any symbol, even one such as @code{car} or @code{x-popup-menu} whose
+normal definition is a primitive. However, this is risky: for
+instance, it is next to impossible to redefine @code{car} without
+breaking Lisp completely. Redefining an obscure function such as
address@hidden is less dangerous, but it still may not work as
+you expect. If there are calls to the primitive from C code, they
+call the primitive's C definition directly, so changing the symbol's
+definition will have no effect on them.
+
+ See also @code{defsubst}, which defines a function like @code{defun}
+and tells the Lisp compiler to open-code it. @xref{Inline Functions}.
+
address@hidden Calling Functions
address@hidden Calling Functions
address@hidden function invocation
address@hidden calling a function
+
+ Defining functions is only half the battle. Functions don't do
+anything until you @dfn{call} them, i.e., tell them to run. Calling a
+function is also known as @dfn{invocation}.
+
+ The most common way of invoking a function is by evaluating a list.
+For example, evaluating the list @code{(concat "a" "b")} calls the
+function @code{concat} with arguments @code{"a"} and @code{"b"}.
address@hidden, for a description of evaluation.
+
+ 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}.
+
address@hidden funcall function &rest arguments
address@hidden calls @var{function} with @var{arguments}, and returns
+whatever @var{function} returns.
+
+Since @code{funcall} is a function, all of its arguments, including
address@hidden, 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}; 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
+they make sense only when given the ``unevaluated'' argument
+expressions. @code{funcall} cannot provide these because, as we saw
+above, it never knows them in the first place.
+
address@hidden
address@hidden
+(setq f 'list)
+ @result{} list
address@hidden group
address@hidden
+(funcall f 'x 'y 'z)
+ @result{} (x y z)
address@hidden group
address@hidden
+(funcall f 'x 'y '(z))
+ @result{} (x y (z))
address@hidden group
address@hidden
+(funcall 'and t nil)
address@hidden Invalid function: #<subr and>
address@hidden group
address@hidden example
+
+Compare these examples with the examples of @code{apply}.
address@hidden defun
+
address@hidden apply function &rest arguments
address@hidden calls @var{function} with @var{arguments}, just like
address@hidden but with one difference: the last of @var{arguments} is a
+list of objects, which are passed to @var{function} as separate
+arguments, rather than a single list. We say that @code{apply}
address@hidden this list so that each individual element becomes an
+argument.
+
address@hidden returns the result of calling @var{function}. As with
address@hidden, @var{function} must either be a Lisp function or a
+primitive function; special forms and macros do not make sense in
address@hidden
+
address@hidden
address@hidden
+(setq f 'list)
+ @result{} list
address@hidden group
address@hidden
+(apply f 'x 'y 'z)
address@hidden Wrong type argument: listp, z
address@hidden group
address@hidden
+(apply '+ 1 2 '(3 4))
+ @result{} 10
address@hidden group
address@hidden
+(apply '+ '(1 2 3 4))
+ @result{} 10
address@hidden group
+
address@hidden
+(apply 'append '((a b c) nil (x y z) nil))
+ @result{} (a b c x y z)
address@hidden group
address@hidden example
+
+For an interesting example of using @code{apply}, see @ref{Definition
+of mapcar}.
address@hidden defun
+
address@hidden functionals
+ It is common for Lisp functions to accept functions as arguments or
+find them in data structures (especially in hook variables and property
+lists) and call them using @code{funcall} or @code{apply}. Functions
+that accept function arguments are often called @dfn{functionals}.
+
+ Sometimes, when you call a functional, it is useful to supply a no-op
+function as the argument. Here are two different kinds of no-op
+function:
+
address@hidden identity arg
+This function returns @var{arg} and has no side effects.
address@hidden defun
+
address@hidden ignore &rest args
+This function ignores any arguments and returns @code{nil}.
address@hidden defun
+
address@hidden Mapping Functions
address@hidden Mapping Functions
address@hidden mapping functions
+
+ A @dfn{mapping function} applies a given function (@emph{not} a
+special form or macro) to each element of a list or other collection.
+Emacs Lisp has several such functions; @code{mapcar} and
address@hidden, which scan a list, are described here.
address@hidden of mapatoms}, for the function @code{mapatoms} which
+maps over the symbols in an obarray. @xref{Definition of maphash},
+for the function @code{maphash} which maps over key/value associations
+in a hash table.
+
+ These mapping functions do not allow char-tables because a char-table
+is a sparse array whose nominal range of indices is very large. To map
+over a char-table in a way that deals properly with its sparse nature,
+use the function @code{map-char-table} (@pxref{Char-Tables}).
+
address@hidden mapcar function sequence
address@hidden of mapcar}
address@hidden applies @var{function} to each element of @var{sequence}
+in turn, and returns a list of the results.
+
+The argument @var{sequence} can be any kind of sequence except a
+char-table; that is, a list, a vector, a bool-vector, or a string. The
+result is always a list. The length of the result is the same as the
+length of @var{sequence}. For example:
+
address@hidden
address@hidden
+(mapcar 'car '((a b) (c d) (e f)))
+ @result{} (a c e)
+(mapcar '1+ [1 2 3])
+ @result{} (2 3 4)
+(mapcar 'char-to-string "abc")
+ @result{} ("a" "b" "c")
address@hidden group
+
address@hidden
+;; @r{Call each function in @code{my-hooks}.}
+(mapcar 'funcall my-hooks)
address@hidden group
+
address@hidden
+(defun mapcar* (function &rest args)
+ "Apply FUNCTION to successive cars of all ARGS.
+Return the list of results."
+ ;; @r{If no list is exhausted,}
+ (if (not (memq nil args))
+ ;; @r{apply function to @sc{car}s.}
+ (cons (apply function (mapcar 'car args))
+ (apply 'mapcar* function
+ ;; @r{Recurse for rest of elements.}
+ (mapcar 'cdr args)))))
address@hidden group
+
address@hidden
+(mapcar* 'cons '(a b c) '(1 2 3 4))
+ @result{} ((a . 1) (b . 2) (c . 3))
address@hidden group
address@hidden smallexample
address@hidden defun
+
address@hidden mapc function sequence
address@hidden is like @code{mapcar} except that @var{function} is used for
+side-effects only---the values it returns are ignored, not collected
+into a list. @code{mapc} always returns @var{sequence}.
address@hidden defun
+
address@hidden mapconcat function sequence separator
address@hidden applies @var{function} to each element of
address@hidden: the results, which must be strings, are concatenated.
+Between each pair of result strings, @code{mapconcat} inserts the string
address@hidden Usually @var{separator} contains a space or comma or
+other suitable punctuation.
+
+The argument @var{function} must be a function that can take one
+argument and return a string. The argument @var{sequence} can be any
+kind of sequence except a char-table; that is, a list, a vector, a
+bool-vector, or a string.
+
address@hidden
address@hidden
+(mapconcat 'symbol-name
+ '(The cat in the hat)
+ " ")
+ @result{} "The cat in the hat"
address@hidden group
+
address@hidden
+(mapconcat (function (lambda (x) (format "%c" (1+ x))))
+ "HAL-8000"
+ "")
+ @result{} "IBM.9111"
address@hidden group
address@hidden smallexample
address@hidden defun
+
address@hidden Anonymous Functions
address@hidden Anonymous Functions
address@hidden anonymous function
+
+ In Lisp, a function is a list that starts with @code{lambda}, a
+byte-code function compiled from such a list, or alternatively a
+primitive subr-object; names are ``extra.'' Although usually functions
+are defined with @code{defun} and given names at the same time, it is
+occasionally more concise to use an explicit lambda expression---an
+anonymous function. Such a list is valid wherever a function name is.
+
+ Any method of creating such a list makes a valid function. Even this:
+
address@hidden
address@hidden
+(setq silly (append '(lambda (x)) (list (list '+ (* 3 4) 'x))))
address@hidden (lambda (x) (+ 12 x))
address@hidden group
address@hidden smallexample
+
address@hidden
+This computes a list that looks like @code{(lambda (x) (+ 12 x))} and
+makes it the value (@emph{not} the function definition!) of
address@hidden
+
+ Here is how we might call this function:
+
address@hidden
address@hidden
+(funcall silly 1)
address@hidden 13
address@hidden group
address@hidden example
+
address@hidden
+(It does @emph{not} work to write @code{(silly 1)}, because this function
+is not the @emph{function definition} of @code{silly}. We have not given
address@hidden any function definition, just a value as a variable.)
+
+ Most of the time, anonymous functions are constants that appear in
+your program. For example, you might want to pass one as an argument to
+the function @code{mapcar}, which applies any given function to each
+element of a list.
+
+ Here we define a function @code{change-property} which
+uses a function as its third argument:
+
address@hidden
address@hidden
+(defun change-property (symbol prop function)
+ (let ((value (get symbol prop)))
+ (put symbol prop (funcall function value))))
address@hidden group
address@hidden example
+
address@hidden
+Here we define a function that uses @code{change-property},
+passing it a function to double a number:
+
address@hidden
address@hidden
+(defun double-property (symbol prop)
+ (change-property symbol prop '(lambda (x) (* 2 x))))
address@hidden group
address@hidden example
+
address@hidden
+In such cases, we usually use the special form @code{function} instead
+of simple quotation to quote the anonymous function, like this:
+
address@hidden
address@hidden
+(defun double-property (symbol prop)
+ (change-property symbol prop
+ (function (lambda (x) (* 2 x)))))
address@hidden group
address@hidden example
+
+Using @code{function} instead of @code{quote} makes a difference if you
+compile the function @code{double-property}. For example, if you
+compile the second definition of @code{double-property}, the anonymous
+function is compiled as well. By contrast, if you compile the first
+definition which uses ordinary @code{quote}, the argument passed to
address@hidden is the precise list shown:
+
address@hidden
+(lambda (x) (* x 2))
address@hidden example
+
address@hidden
+The Lisp compiler cannot assume this list is a function, even though it
+looks like one, since it does not know what @code{change-property} will
+do with the list. Perhaps it will check whether the @sc{car} of the third
+element is the symbol @code{*}! Using @code{function} tells the
+compiler it is safe to go ahead and compile the constant function.
+
+ Nowadays it is possible to omit @code{function} entirely, like this:
+
address@hidden
address@hidden
+(defun double-property (symbol prop)
+ (change-property symbol prop (lambda (x) (* 2 x))))
address@hidden group
address@hidden example
+
address@hidden
+This is because @code{lambda} itself implies @code{function}.
+
+ We sometimes write @code{function} instead of @code{quote} when
+quoting the name of a function, but this usage is just a sort of
+comment:
+
address@hidden
+(function @var{symbol}) @equiv{} (quote @var{symbol}) @equiv{} '@var{symbol}
address@hidden example
+
address@hidden @samp{#'} syntax
+ The read syntax @code{#'} is a short-hand for using @code{function}.
+For example,
+
address@hidden
+#'(lambda (x) (* x x))
address@hidden example
+
address@hidden
+is equivalent to
+
address@hidden
+(function (lambda (x) (* x x)))
address@hidden example
+
address@hidden function function-object
address@hidden function quoting
+This special form returns @var{function-object} without evaluating it.
+In this, it is equivalent to @code{quote}. However, it serves as a
+note to the Emacs Lisp compiler that @var{function-object} is intended
+to be used only as a function, and therefore can safely be compiled.
+Contrast this with @code{quote}, in @ref{Quoting}.
address@hidden defspec
+
+ @xref{describe-symbols example}, for a realistic example using
address@hidden and an anonymous function.
+
address@hidden Function Cells
address@hidden Accessing Function Cell Contents
+
+ The @dfn{function definition} of a symbol is the object stored in the
+function cell of the symbol. The functions described here access, test,
+and set the function cell of symbols.
+
+ See also the function @code{indirect-function}. @xref{Definition of
+indirect-function}.
+
address@hidden symbol-function symbol
address@hidden void-function
+This returns the object in the function cell of @var{symbol}. If the
+symbol's function cell is void, a @code{void-function} error is
+signaled.
+
+This function does not check that the returned object is a legitimate
+function.
+
address@hidden
address@hidden
+(defun bar (n) (+ n 2))
+ @result{} bar
address@hidden group
address@hidden
+(symbol-function 'bar)
+ @result{} (lambda (n) (+ n 2))
address@hidden group
address@hidden
+(fset 'baz 'bar)
+ @result{} bar
address@hidden group
address@hidden
+(symbol-function 'baz)
+ @result{} bar
address@hidden group
address@hidden example
address@hidden defun
+
address@hidden void function cell
+ If you have never given a symbol any function definition, we say that
+that symbol's function cell is @dfn{void}. In other words, the function
+cell does not have any Lisp object in it. If you try to call such a symbol
+as a function, it signals a @code{void-function} error.
+
+ Note that void is not the same as @code{nil} or the symbol
address@hidden The symbols @code{nil} and @code{void} are Lisp objects,
+and can be stored into a function cell just as any other object can be
+(and they can be valid functions if you define them in turn with
address@hidden). A void function cell contains no object whatsoever.
+
+ You can test the voidness of a symbol's function definition with
address@hidden After you have given a symbol a function definition, you
+can make it void once more using @code{fmakunbound}.
+
address@hidden fboundp symbol
+This function returns @code{t} if the symbol has an object in its
+function cell, @code{nil} otherwise. It does not check that the object
+is a legitimate function.
address@hidden defun
+
address@hidden fmakunbound symbol
+This function makes @var{symbol}'s function cell void, so that a
+subsequent attempt to access this cell will cause a
address@hidden error. It returns @var{symbol}. (See also
address@hidden, in @ref{Void Variables}.)
+
address@hidden
address@hidden
+(defun foo (x) x)
+ @result{} foo
address@hidden group
address@hidden
+(foo 1)
+ @result{}1
address@hidden group
address@hidden
+(fmakunbound 'foo)
+ @result{} foo
address@hidden group
address@hidden
+(foo 1)
address@hidden Symbol's function definition is void: foo
address@hidden group
address@hidden example
address@hidden defun
+
address@hidden fset symbol definition
+This function stores @var{definition} in the function cell of
address@hidden The result is @var{definition}. Normally
address@hidden should be a function or the name of a function, but
+this is not checked. The argument @var{symbol} is an ordinary evaluated
+argument.
+
+There are three normal uses of this function:
+
address@hidden @bullet
address@hidden
+Copying one symbol's function definition to another---in other words,
+making an alternate name for a function. (If you think of this as the
+definition of the new name, you should use @code{defalias} instead of
address@hidden; see @ref{Definition of defalias}.)
+
address@hidden
+Giving a symbol a function definition that is not a list and therefore
+cannot be made with @code{defun}. For example, you can use @code{fset}
+to give a symbol @code{s1} a function definition which is another symbol
address@hidden; then @code{s1} serves as an alias for whatever definition
address@hidden presently has. (Once again use @code{defalias} instead of
address@hidden if you think of this as the definition of @code{s1}.)
+
address@hidden
+In constructs for defining or altering functions. If @code{defun}
+were not a primitive, it could be written in Lisp (as a macro) using
address@hidden
address@hidden itemize
+
+Here are examples of these uses:
+
address@hidden
address@hidden
+;; @r{Save @code{foo}'s definition in @code{old-foo}.}
+(fset 'old-foo (symbol-function 'foo))
address@hidden group
+
address@hidden
+;; @r{Make the symbol @code{car} the function definition of @code{xfirst}.}
+;; @r{(Most likely, @code{defalias} would be better than @code{fset} here.)}
+(fset 'xfirst 'car)
+ @result{} car
address@hidden group
address@hidden
+(xfirst '(1 2 3))
+ @result{} 1
address@hidden group
address@hidden
+(symbol-function 'xfirst)
+ @result{} car
address@hidden group
address@hidden
+(symbol-function (symbol-function 'xfirst))
+ @result{} #<subr car>
address@hidden group
+
address@hidden
+;; @r{Define a named keyboard macro.}
+(fset 'kill-two-lines "\^u2\^k")
+ @result{} "\^u2\^k"
address@hidden group
+
address@hidden
+;; @r{Here is a function that alters other functions.}
+(defun copy-function-definition (new old)
+ "Define NEW with the same function definition as OLD."
+ (fset new (symbol-function old)))
address@hidden group
address@hidden example
address@hidden defun
+
+ @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
address@hidden (@pxref{Advising Functions}).
+
address@hidden Obsolete Functions
address@hidden 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.
+
address@hidden make-obsolete obsolete-name current-name &optional when
+This function makes the byte compiler warn that the function
address@hidden is obsolete. If @var{current-name} is a symbol, the
+warning message says to use @var{current-name} instead of
address@hidden @var{current-name} does not need to be an alias for
address@hidden; 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.
address@hidden defun
+
+You can define a function as an alias and declare it obsolete at the
+same time using the macro @code{define-obsolete-function-alias}.
+
address@hidden 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:
+
address@hidden
+(defalias @var{obsolete-name} @var{current-name} @var{docstring})
+(make-obsolete @var{obsolete-name} @var{current-name} @var{when})
address@hidden example
address@hidden defmac
+
address@hidden Inline Functions
address@hidden Inline Functions
address@hidden inline functions
+
address@hidden defsubst
+You can define an @dfn{inline function} by using @code{defsubst} instead
+of @code{defun}. An inline function works just like an ordinary
+function except for one thing: when you compile a call to the function,
+the function's definition is open-coded into the caller.
+
+Making a function inline makes explicit calls run faster. But it also
+has disadvantages. For one thing, it reduces flexibility; if you
+change the definition of the function, calls already inlined still use
+the old definition until you recompile them.
+
+Another disadvantage is that making a large function inline can increase
+the size of compiled code both in files and in memory. Since the speed
+advantage of inline functions is greatest for small functions, you
+generally should not make large functions inline.
+
+Also, inline functions do not behave well with respect to debugging,
+tracing, and advising (@pxref{Advising Functions}). Since ease of
+debugging and the flexibility of redefining functions are important
+features of Emacs, you should not make a function inline, even if it's
+small, unless its speed is really crucial, and you've timed the code
+to verify that using @code{defun} actually has performance problems.
+
+It's possible to define a macro to expand into the same code that an
+inline function would execute. (@xref{Macros}.) But the macro would be
+limited to direct use in expressions---a macro cannot be called with
address@hidden, @code{mapcar} and so on. Also, it takes some work to
+convert an ordinary function into a macro. To convert it into an inline
+function is very easy; simply replace @code{defun} with @code{defsubst}.
+Since each argument of an inline function is evaluated exactly once, you
+needn't worry about how many times the body uses the arguments, as you
+do for macros. (@xref{Argument Evaluation}.)
+
+Inline functions can be used and open-coded later on in the same file,
+following the definition, just like macros.
+
address@hidden Function Safety
address@hidden Determining whether a Function is Safe to Call
address@hidden function safety
address@hidden safety of functions
+
+Some major modes such as SES call functions that are stored in user
+files. (@inforef{Top, ,ses}, for more information on SES.) User
+files sometimes have poor pedigrees---you can get a spreadsheet from
+someone you've just met, or you can get one through email from someone
+you've never met. So it is risky to call a function whose source code
+is stored in a user file until you have determined that it is safe.
+
address@hidden unsafep form &optional unsafep-vars
+Returns @code{nil} if @var{form} is a @dfn{safe} Lisp expression, or
+returns a list that describes why it might be unsafe. The argument
address@hidden is a list of symbols known to have temporary
+bindings at this point; it is mainly used for internal recursive
+calls. The current buffer is an implicit argument, which provides a
+list of buffer-local bindings.
address@hidden defun
+
+Being quick and simple, @code{unsafep} does a very light analysis and
+rejects many Lisp expressions that are actually safe. There are no
+known cases where @code{unsafep} returns @code{nil} for an unsafe
+expression. However, a ``safe'' Lisp expression can return a string
+with a @code{display} property, containing an associated Lisp
+expression to be executed after the string is inserted into a buffer.
+This associated expression can be a virus. In order to be safe, you
+must delete properties from all strings calculated by user code before
+inserting them into buffers.
+
address@hidden
+What is a safe Lisp expression? Basically, it's an expression that
+calls only built-in functions with no side effects (or only innocuous
+ones). Innocuous side effects include displaying messages and
+altering non-risky buffer-local variables (but not global variables).
+
address@hidden @dfn
address@hidden Safe expression
address@hidden
address@hidden
+An atom or quoted thing.
address@hidden
+A call to a safe function (see below), if all its arguments are
+safe expressions.
address@hidden
+One of the special forms @code{and}, @code{catch}, @code{cond},
address@hidden, @code{or}, @code{prog1}, @code{prog2}, @code{progn},
address@hidden, and @code{unwind-protect}], if all its arguments are
+safe.
address@hidden
+A form that creates temporary bindings (@code{condition-case},
address@hidden, @code{dotimes}, @code{lambda}, @code{let}, or
address@hidden), if all args are safe and the symbols to be bound are not
+explicitly risky (see @pxref{File Local Variables}).
address@hidden
+An assignment using @code{add-to-list}, @code{setq}, @code{push}, or
address@hidden, if all args are safe and the symbols to be assigned are
+not explicitly risky and they already have temporary or buffer-local
+bindings.
address@hidden
+One of [apply, mapc, mapcar, mapconcat] if the first argument is a
+safe explicit lambda and the other args are safe expressions.
address@hidden itemize
+
address@hidden Safe function
address@hidden
address@hidden
+A lambda containing safe expressions.
address@hidden
+A symbol on the list @code{safe-functions}, so the user says it's safe.
address@hidden
+A symbol with a address@hidden @code{side-effect-free} property.
address@hidden
+A symbol with a address@hidden @code{safe-function} property. Value t
+indicates a function that is safe but has innocuous side effects.
+Other values will someday indicate functions with classes of side
+effects that are not always safe.
address@hidden itemize
+
+The @code{side-effect-free} and @code{safe-function} properties are
+provided for built-in functions and for low-level functions and macros
+defined in @file{subr.el}. You can assign these properties for the
+functions you write.
address@hidden table
address@hidden ignore
+
address@hidden Related Topics
address@hidden Other Topics Related to Functions
+
+ Here is a table of several functions that do things related to
+function calling and function definitions. They are documented
+elsewhere, but we provide cross references here.
+
address@hidden @code
address@hidden apply
+See @ref{Calling Functions}.
+
address@hidden autoload
+See @ref{Autoload}.
+
address@hidden call-interactively
+See @ref{Interactive Call}.
+
address@hidden commandp
+See @ref{Interactive Call}.
+
address@hidden documentation
+See @ref{Accessing Documentation}.
+
address@hidden eval
+See @ref{Eval}.
+
address@hidden funcall
+See @ref{Calling Functions}.
+
address@hidden function
+See @ref{Anonymous Functions}.
+
address@hidden ignore
+See @ref{Calling Functions}.
+
address@hidden indirect-function
+See @ref{Function Indirection}.
+
address@hidden interactive
+See @ref{Using Interactive}.
+
address@hidden interactive-p
+See @ref{Interactive Call}.
+
address@hidden mapatoms
+See @ref{Creating Symbols}.
+
address@hidden mapcar
+See @ref{Mapping Functions}.
+
address@hidden map-char-table
+See @ref{Char-Tables}.
+
address@hidden mapconcat
+See @ref{Mapping Functions}.
+
address@hidden undefined
+See @ref{Functions for Key Lookup}.
address@hidden table
+
address@hidden
+ arch-tag: 39100cdf-8a55-4898-acba-595db619e8e2
address@hidden ignore