Re: Sv: Subrp returns nil for function objects and symbols? Is this a bug or me misunderstanding it?

[Stephen Berman <stephen.berman@gmx.net>]

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