>>>>> On Thu, 13 Jan 2022 03:49:27 -0500 (EST), Lars Ingebrigtsen <larsi@gnus.org> said:
Lars> branch: master
Lars> commit c8a2af3037c647bf6dd53f53af1b344e284f809b
Lars> Author: Lars Ingebrigtsen <larsi@gnus.org>
Lars> Commit: Lars Ingebrigtsen <larsi@gnus.org>
Lars> Add new function function-alias-p
Lars> * doc/lispref/functions.texi (Defining Functions): Document it.
Lars> * lisp/subr.el (function-alias-p): New function (bug#53178).
Lars> ---
Lars> doc/lispref/functions.texi | 17 +++++++++++++++++
Lars> etc/NEWS | 5 +++++
Lars> lisp/subr.el | 22 ++++++++++++++++++++++
Lars> test/lisp/subr-tests.el | 17 +++++++++++++++++
Lars> 4 files changed, 61 insertions(+)
Lars> diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
Lars> index 96fecc8c89..caf8e3444f 100644
Lars> --- a/doc/lispref/functions.texi
Lars> +++ b/doc/lispref/functions.texi
Lars> @@ -667,6 +667,23 @@ which file defined the function, just like @code{defun}
Lars> By contrast, in programs that manipulate function definitions for other
Lars> purposes, it is better to use @code{fset}, which does not keep such
Lars> records. @xref{Function Cells}.
Lars> +@end defun
Lars> +
Lars> +@defun function-alias-p object &optional noerror
Lars> +Use the @code{function-alias-p} function to check whether an object is
Lars> +a function alias. If it isn't, this predicate will return
Lars> +non-@code{nil}. If it is, the value returned will be a list of symbol
Lars> +representing the function alias chain. For instance, if @code{a} is
Lars> +an alias for @code{b}, and @code{b} is an alias for @code{c}:
Lars> +
I think thatʼs not correct (and a bit convoluted). How about:
Checks whether @var{object} is a function alias. If it is, it returns
a list of symbols representing the function alias chain, else
@code{nil}. For instance, if @code{a} is an alias for @code{b}, and
@code{b} is an alias for @code{c}:
Robert
--
> +@example
> +(function-alias-p 'a)
> + @result{} (b c)
> +@end example
Hmm... would it make sense to return `(b c . <foo>)` where <foo> is the
"last, non-symbol, value", i.e. (symbol-function 'c)?
It seems in most cases where we'd use `function-alias-p` we want to
follow the trail of aliases and then do something on the final
non-alias definition.
Stefan
Robert Pluim <rpluim@gmail.com> writes: > I think thatʼs not correct (and a bit convoluted). How about: > > Checks whether @var{object} is a function alias. If it is, it returns > a list of symbols representing the function alias chain, else > @code{nil}. For instance, if @code{a} is an alias for @code{b}, and > @code{b} is an alias for @code{c}: Yup; now installed. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Stefan Monnier <monnier@iro.umontreal.ca> writes: > Hmm... would it make sense to return `(b c . <foo>)` where <foo> is the > "last, non-symbol, value", i.e. (symbol-function 'c)? > > It seems in most cases where we'd use `function-alias-p` we want to > follow the trail of aliases and then do something on the final > non-alias definition. In the two use cases I had here, one wanted to have the final symbol (for *Help*) and the other wanted to have all the symbols (to check symbol properties). An the semantics would be kinda odd -- in the non-alias case, we'd still return nil, right? So the user still has to use symbol-function on something, so I think the current definition (stop at the last symbol) is the one that's more practical. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
> An the semantics would be kinda odd -- in the non-alias case, we'd still
> return nil, right?
No, I was thinking of returning the content of `symbol-function`.
So, it basically returns a more explicit info than `indirect-function`.
Stefan
Stefan Monnier <monnier@iro.umontreal.ca> writes: >> An the semantics would be kinda odd -- in the non-alias case, we'd still >> return nil, right? > > No, I was thinking of returning the content of `symbol-function`. > So, it basically returns a more explicit info than `indirect-function`. My feeling is that people that want to get at the function object will use `indirect-function'. Callers that want both the intermediate chain and the final object are pretty rare, I think. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
>>> An the semantics would be kinda odd -- in the non-alias case, we'd still
>>> return nil, right?
>> No, I was thinking of returning the content of `symbol-function`.
>> So, it basically returns a more explicit info than `indirect-function`.
> My feeling is that people that want to get at the function object will
> use `indirect-function'. Callers that want both the intermediate chain
> and the final object are pretty rare, I think.
Could be. I was thinking of cases like `interactive-form`, `commandp`,
and `documentation` where we usually want to fetch the info off of the
function object, but we need to check some symbol property along the way
in case it shadows the function's own value.
These functions currently start with `indirect-function` to rule out the
presence of cycles and then proceed to loop through the aliases (if
any).
Stefan
Stefan Monnier <monnier@iro.umontreal.ca> writes: > Could be. I was thinking of cases like `interactive-form`, `commandp`, > and `documentation` where we usually want to fetch the info off of the > function object, but we need to check some symbol property along the way > in case it shadows the function's own value. Right. But looking at `commandp', for instance -- I don't think we could usefully use `function-alias-p' there anyway, no matter what it returns, so changing the value from `function-alias-p' based on `commandp' usage doesn't seem all that pertinent. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no