>>> > (subrp 'car) => nil
>>> > (subrp #'car) => nil
>>> > (subrp '+) => nil
>>> >
>>> > (subrp (symbol-function 'car)) => t
>>> >
>>> > According to the doc, subrp should tell me if "OBJECT" is a built-in
>>> > function or not. I would expect "car" to be that, since car is implemented
>>> > in the C source (in data.c).
>>> >
>>> > I also get the same behavior for compiled-function-p.
>>> >
>>> > Is it not valid to pass a symbol and function objects to those two
>>> > functions? Can we in that case clarify in the doc string expected
>>> > value(s) for OBJECT?
>>>
>>> At least it's documented in the Elisp manual (info "(elisp) What Is a
>>> Function"):
>>
>> Yes. I see it now. I was just looking at function docs previously. Thanks.
>>
>>> Unlike ‘functionp’, the next functions do _not_ treat a symbol as its
>>> function definition.
>>>
>>> -- Function: subrp object
>>> This function returns ‘t’ if OBJECT is a built-in function (i.e., a
>>> Lisp primitive).
>>>
>>> (subrp 'message) ; ‘message’ is a symbol,
>>> ⇒ nil ; not a subr object.
>>> (subrp (symbol-function 'message))
>>> ⇒ t
>>
>> Ok, they are explicit it does not look at function slot of a symbol itself
>> (2.4.15). However, I find the documentation a bit vague or perhaps outdated.
>> In
>> particular regarding the "built-in" type. Perhaps this function
>> historically meant something else than how it works today (I think it did). I
>> guess built-in used to mean "implemented in C core", but since the native
>> compiler come in, it seems to rapport any machine-code compiled function as
>> "subr":
>>
>> (defun test-fn () (message "hi"))
>> (native-compile 'test-fn)
>> (subrp (symbol-function 'test-fn)) => t
>>
>> In other words, perhaps manual should be updated to say something along the
>> line
>> that subrp tells if function is a function compiled to machine code. I see now
>> also that compiled-function-p repports if a function is both byte-code
>> compiled
>> and machine-code compiled as "compiled" so those are not equal.
>
>Yes, it does seem that the semantics of `subr' have changed (at least
>conceptually, if not formally, though perhaps that too) since the
>introduction of native compilation. Note also:
>
>(subr-arity (symbol-function 'test-fn)) => (0 . 0)
>
>In contrast:
>
>(primitive-function-p (symbol-function 'test-fn)) => nil
>(primitive-function-p (symbol-function 'car)) => t
Indeed. Sorry for a bit late answer; was testing things out and looking at the
manual, and than saw the answer from Andrea, so I answered that one.
Seems like subrs are a superset of both primitive functions and compiled lisp
functions, in other words any compiled function (not special form or macro). If
I am interpretting it correctly. Basically what I wrote in the answer to Andrea.
Från: Stephen Berman <stephen.berman@gmx.net>
Skickat: den 14 augusti 2024 12:08
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Sv: Subrp returns nil for function objects and symbols? Is this a bug or me misunderstanding it?
On Tue, 13 Aug 2024 18:00:12 +0000 arthur miller <arthur.miller@live.com> wrote:
>> > (subrp 'car) => nil
>> > (subrp #'car) => nil
>> > (subrp '+) => nil
>> >
>> > (subrp (symbol-function 'car)) => t
>> >
>> > According to the doc, subrp should tell me if "OBJECT" is a built-in
>> > function or not. I would expect "car" to be that, since car is implemented
>> > in the C source (in data.c).
>> >
>> > I also get the same behavior for compiled-function-p.
>> >
>> > Is it not valid to pass a symbol and function objects to those two
>> > functions? Can we in that case clarify in the doc string expected
>> > value(s) for OBJECT?
>>
>> At least it's documented in the Elisp manual (info "(elisp) What Is a
>> Function"):
>
> Yes. I see it now. I was just looking at function docs previously. Thanks.
>
>> Unlike ‘functionp’, the next functions do _not_ treat a symbol as its
>> function definition.
>>
>> -- Function: subrp object
>> This function returns ‘t’ if OBJECT is a built-in function (i.e., a
>> Lisp primitive).
>>
>> (subrp 'message) ; ‘message’ is a symbol,
>> ⇒ nil ; not a subr object.
>> (subrp (symbol-function 'message))
>> ⇒ t
>
> Ok, they are explicit it does not look at function slot of a symbol itself
> (2.4.15). However, I find the documentation a bit vague or perhaps outdated. In
> particular regarding the "built-in" type. Perhaps this function
> historically meant something else than how it works today (I think it did). I
> guess built-in used to mean "implemented in C core", but since the native
> compiler come in, it seems to rapport any machine-code compiled function as
> "subr":
>
> (defun test-fn () (message "hi"))
> (native-compile 'test-fn)
> (subrp (symbol-function 'test-fn)) => t
>
> In other words, perhaps manual should be updated to say something along the line
> that subrp tells if function is a function compiled to machine code. I see now
> also that compiled-function-p repports if a function is both byte-code compiled
> and machine-code compiled as "compiled" so those are not equal.
Yes, it does seem that the semantics of `subr' have changed (at least
conceptually, if not formally, though perhaps that too) since the
introduction of native compilation. Note also:
(subr-arity (symbol-function 'test-fn)) => (0 . 0)
In contrast:
(primitive-function-p (symbol-function 'test-fn)) => nil
(primitive-function-p (symbol-function 'car)) => t
Steve Berman