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

[Andrea Corallo <acorallo@gnu.org>]

Stephen Berman <stephen.berman@gmx.net> writes:

> 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

Hi Steve,

The semantic of 'subrp' (and 'subr-arity') is not changed, what has
changed is that built-in functions are not anymore the only exinsting
subr because native compile Lisp functions are subr as well.

I've updated the docstring of 'subrp'.

  Andrea