comparison lispref/functions.texi @ 90796:4ef881a120fe

Merge from emacs--devo--0 Patches applied: * emacs--devo--0 (patch 675-697) - Update from CVS - Merge from gnus--rel--5.10 - Release ERC 5.2. * gnus--rel--5.10 (patch 211-215) - Update from CVS - Merge from emacs--devo--0 Revision: [e-mail]/emacs--unicode--0--patch-189

90795:b9182b6a90c9

@node Argument List
@subsection Other Features of Argument Lists
@kindex wrong-number-of-arguments
@cindex argument binding
@cindex binding arguments

  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.

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.
@end defspec

@defun defalias name definition &optional docstring
@anchor{Definition 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}.

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.  Since the flexibility of
redefining functions is an important feature of Emacs, you should not
make a function inline unless its speed is really crucial.

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.

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
@code{apply}, @code{mapcar} and so on.  Also, it takes some work to

90796:4ef881a120fe

@node Argument List
@subsection Other Features of Argument Lists
@kindex wrong-number-of-arguments
@cindex argument binding
@cindex binding arguments
@cindex 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.

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.
@end defspec

@cindex function aliases
@defun defalias name definition &optional docstring
@anchor{Definition 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}.

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
@code{apply}, @code{mapcar} and so on.  Also, it takes some work to