diff options
| author | Eli Zaretskii | 2016-01-16 15:30:47 +0200 |
|---|---|---|
| committer | Eli Zaretskii | 2016-01-16 15:30:47 +0200 |
| commit | e48f6dd3f79229d1dca96a691069eba45e90480c (patch) | |
| tree | 966ede3f66f8626081b1d733ea039f37466e89af | |
| parent | 6e79b6379fa33aef914211b280d0ee0b08d0339a (diff) | |
| download | emacs-e48f6dd3f79229d1dca96a691069eba45e90480c.tar.gz emacs-e48f6dd3f79229d1dca96a691069eba45e90480c.zip | |
Document 'define-inline'
* doc/lispref/functions.texi (Defining Functions): Document
'define-inline' and related macros.
* lisp/emacs-lisp/inline.el (inline-letevals): Doc fix.
| -rw-r--r-- | doc/lispref/functions.texi | 115 | ||||
| -rw-r--r-- | etc/NEWS | 1 | ||||
| -rw-r--r-- | lisp/emacs-lisp/inline.el | 2 |
3 files changed, 107 insertions, 11 deletions
diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi index e596badcdd2..d3d0a422574 100644 --- a/doc/lispref/functions.texi +++ b/doc/lispref/functions.texi | |||
| @@ -623,6 +623,96 @@ definition will have no effect on them. | |||
| 623 | and tells the Lisp compiler to perform inline expansion on it. | 623 | and tells the Lisp compiler to perform inline expansion on it. |
| 624 | @xref{Inline Functions}. | 624 | @xref{Inline Functions}. |
| 625 | 625 | ||
| 626 | Alternatively, you can define a function by providing the code which | ||
| 627 | will inline it as a compiler macro. The following macros make this | ||
| 628 | possible. | ||
| 629 | |||
| 630 | @c FIXME: Can define-inline use the interactive spec? | ||
| 631 | @defmac define-inline name args [doc] [declare] body@dots{} | ||
| 632 | Define a function @var{name} by providing code that does its inlining, | ||
| 633 | as a compiler macro. The function will accept the argument list | ||
| 634 | @var{args} and will have the specified @var{body}. | ||
| 635 | |||
| 636 | If present, @var{doc} should be the function's documentation string | ||
| 637 | (@pxref{Function Documentation}); @var{declare}, if present, should be | ||
| 638 | a @code{declare} form (@pxref{Declare Form}) specifying the function's | ||
| 639 | metadata. | ||
| 640 | @end defmac | ||
| 641 | |||
| 642 | Functions defined via @code{define-inline} have several advantages | ||
| 643 | with respect to macros defined by @code{defsubst} or @code{defmacro}: | ||
| 644 | |||
| 645 | @itemize @minus | ||
| 646 | @item | ||
| 647 | They can be passed to @code{mapcar} (@pxref{Mapping Functions}). | ||
| 648 | |||
| 649 | @item | ||
| 650 | They are more efficient. | ||
| 651 | |||
| 652 | @item | ||
| 653 | They can be used as @dfn{place forms} to store values | ||
| 654 | (@pxref{Generalized Variables}). | ||
| 655 | |||
| 656 | @item | ||
| 657 | They behave in a more predictable way than @code{cl-defsubst} | ||
| 658 | (@pxref{Argument Lists,,, cl, Common Lisp Extensions for GNU Emacs | ||
| 659 | Lisp}). | ||
| 660 | @end itemize | ||
| 661 | |||
| 662 | Like @code{defmacro}, a function inlined with @code{define-inline} | ||
| 663 | inherits the scoping rules, either dynamic or lexical, from the call | ||
| 664 | site. @xref{Variable Scoping}. | ||
| 665 | |||
| 666 | The following macros should be used in the body of a function defined | ||
| 667 | by @code{define-inline}. | ||
| 668 | |||
| 669 | @defmac inline-quote expression | ||
| 670 | Quote @var{expression} for @code{define-inline}. This is similar to | ||
| 671 | the backquote (@pxref{Backquote}), but quotes code and accepts only | ||
| 672 | @code{,}, not @code{,@@}. | ||
| 673 | @end defmac | ||
| 674 | |||
| 675 | @defmac inline-letevals (bindings@dots{}) body@dots{} | ||
| 676 | This is is similar to @code{let} (@pxref{Local Variables}): it sets up | ||
| 677 | local variables as specified by @var{bindings}, and then evaluates | ||
| 678 | @var{body} with those bindings in effect. Each element of | ||
| 679 | @var{bindings} should be either a symbol or a list of the form | ||
| 680 | @w{@code{(@var{var} @var{expr})}}; the result is to evaluate | ||
| 681 | @var{expr} and bind @var{var} to the result. The tail of | ||
| 682 | @var{bindings} can be either @code{nil} or a symbol which should hold | ||
| 683 | a list of arguments, in which case each argument is evaluated, and the | ||
| 684 | symbol is bound to the resulting list. | ||
| 685 | @end defmac | ||
| 686 | |||
| 687 | @defmac inline-const-p expression | ||
| 688 | Return non-@code{nil} if the value of @var{expression} is already | ||
| 689 | known. | ||
| 690 | @end defmac | ||
| 691 | |||
| 692 | @defmac inline-const-val expression | ||
| 693 | Return the value of @var{expression}. | ||
| 694 | @end defmac | ||
| 695 | |||
| 696 | @defmac inline-error format &rest args | ||
| 697 | Signal an error, formatting @var{args} according to @var{format}. | ||
| 698 | @end defmac | ||
| 699 | |||
| 700 | Here's an example of using @code{define-inline}: | ||
| 701 | |||
| 702 | @lisp | ||
| 703 | (define-inline myaccessor (obj) | ||
| 704 | (inline-letevals (obj) | ||
| 705 | (inline-quote (if (foo-p ,obj) (aref (cdr ,obj) 3) (aref ,obj 2))))) | ||
| 706 | @end lisp | ||
| 707 | |||
| 708 | @noindent | ||
| 709 | This is equivalent to | ||
| 710 | |||
| 711 | @lisp | ||
| 712 | (defsubst myaccessor (obj) | ||
| 713 | (if (foo-p obj) (aref (cdr obj) 3) (aref obj 2))) | ||
| 714 | @end lisp | ||
| 715 | |||
| 626 | @node Calling Functions | 716 | @node Calling Functions |
| 627 | @section Calling Functions | 717 | @section Calling Functions |
| 628 | @cindex function invocation | 718 | @cindex function invocation |
| @@ -1706,19 +1796,24 @@ features of Emacs, you should not make a function inline, even if it's | |||
| 1706 | small, unless its speed is really crucial, and you've timed the code | 1796 | small, unless its speed is really crucial, and you've timed the code |
| 1707 | to verify that using @code{defun} actually has performance problems. | 1797 | to verify that using @code{defun} actually has performance problems. |
| 1708 | 1798 | ||
| 1709 | It's possible to define a macro to expand into the same code that an | ||
| 1710 | inline function would execute (@pxref{Macros}). But the macro would | ||
| 1711 | be limited to direct use in expressions---a macro cannot be called | ||
| 1712 | with @code{apply}, @code{mapcar} and so on. Also, it takes some work | ||
| 1713 | to convert an ordinary function into a macro. To convert it into an | ||
| 1714 | inline function is easy; just replace @code{defun} with | ||
| 1715 | @code{defsubst}. Since each argument of an inline function is | ||
| 1716 | evaluated exactly once, you needn't worry about how many times the | ||
| 1717 | body uses the arguments, as you do for macros. | ||
| 1718 | |||
| 1719 | After an inline function is defined, its inline expansion can be | 1799 | After an inline function is defined, its inline expansion can be |
| 1720 | performed later on in the same file, just like macros. | 1800 | performed later on in the same file, just like macros. |
| 1721 | 1801 | ||
| 1802 | It's possible to use @code{defsubst} to define a macro to expand | ||
| 1803 | into the same code that an inline function would execute | ||
| 1804 | (@pxref{Macros}). But the macro would be limited to direct use in | ||
| 1805 | expressions---a macro cannot be called with @code{apply}, | ||
| 1806 | @code{mapcar} and so on. Also, it takes some work to convert an | ||
| 1807 | ordinary function into a macro. To convert it into an inline function | ||
| 1808 | is easy; just replace @code{defun} with @code{defsubst}. Since each | ||
| 1809 | argument of an inline function is evaluated exactly once, you needn't | ||
| 1810 | worry about how many times the body uses the arguments, as you do for | ||
| 1811 | macros. | ||
| 1812 | |||
| 1813 | As an alternative to @code{defsubst}, you can use | ||
| 1814 | @code{define-inline} to define functions via their exhaustive compiler | ||
| 1815 | macro. @xref{Defining Functions, define-inline}. | ||
| 1816 | |||
| 1722 | @node Declare Form | 1817 | @node Declare Form |
| 1723 | @section The @code{declare} Form | 1818 | @section The @code{declare} Form |
| 1724 | @findex declare | 1819 | @findex declare |
| @@ -1425,6 +1425,7 @@ details. | |||
| 1425 | It should be placed right where the docstring would be, and FORM is then | 1425 | It should be placed right where the docstring would be, and FORM is then |
| 1426 | evaluated (and should return a string) when the closure is built. | 1426 | evaluated (and should return a string) when the closure is built. |
| 1427 | 1427 | ||
| 1428 | +++ | ||
| 1428 | ** define-inline provides a new way to define inlinable functions. | 1429 | ** define-inline provides a new way to define inlinable functions. |
| 1429 | 1430 | ||
| 1430 | ** New function `macroexpand-1' to perform a single step of macroexpansion. | 1431 | ** New function `macroexpand-1' to perform a single step of macroexpansion. |
diff --git a/lisp/emacs-lisp/inline.el b/lisp/emacs-lisp/inline.el index 56780fbb05a..058c56c3b49 100644 --- a/lisp/emacs-lisp/inline.el +++ b/lisp/emacs-lisp/inline.el | |||
| @@ -102,7 +102,7 @@ VARS should be a list of elements of the form (VAR EXP) or just VAR, in case | |||
| 102 | EXP is equal to VAR. The result is to evaluate EXP and bind the result to VAR. | 102 | EXP is equal to VAR. The result is to evaluate EXP and bind the result to VAR. |
| 103 | 103 | ||
| 104 | The tail of VARS can be either nil or a symbol VAR which should hold a list | 104 | The tail of VARS can be either nil or a symbol VAR which should hold a list |
| 105 | of arguments,in which case each argument is evaluated and the resulting | 105 | of arguments, in which case each argument is evaluated and the resulting |
| 106 | new list is re-bound to VAR. | 106 | new list is re-bound to VAR. |
| 107 | 107 | ||
| 108 | After VARS is handled, BODY is evaluated in the new environment." | 108 | After VARS is handled, BODY is evaluated in the new environment." |