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

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

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

(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?


[-- Attachment #2: Type: text/html, Size: 2603 bytes --]

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

[Stephen Berman]

On Tue, 13 Aug 2024 09:22:01 +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"):

  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

Steve Berman

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

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 3545 bytes --]

> > (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.
________________________________
Från: Stephen Berman <stephen.berman@gmx.net>
Skickat: den 13 augusti 2024 13:08
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Subrp returns nil for function objects and symbols? Is this a bug or me misunderstanding it?

On Tue, 13 Aug 2024 09:22:01 +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"):

  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

Steve Berman

[-- Attachment #2: Type: text/html, Size: 10774 bytes --]

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

[Stephen Berman]

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

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

[Andrea Corallo]

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

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

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 9633 bytes --]

>> 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,
>

I hope I am also allowed to chim-in here:

>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.

If you don't mind, what is the semantic of subr? The manual says:

“primitive”
     A function which is callable from Lisp but is actually written in
     C.  Primitives are also called “built-in functions”, or “subrs”.
     Examples include functions like ‘car’ and ‘append’.  In addition,
     all special forms (see below) are also considered primitives.

     Usually, a function is implemented as a primitive because it is a
     fundamental part of Lisp (e.g., ‘car’), or because it provides a
     low-level interface to operating system services, or because it
     needs to run fast.  Unlike functions defined in Lisp, primitives
     can be modified or added only by changing the C sources and
     recompiling Emacs.  See *note Writing Emacs Primitives::.

Can I assume that semantic of subr means a machine code compiled function,
regardles of the origin (C code or compiled Lisp code), but not unevalled
forms and macros? An equivalent to compiled-function-p in Common Lisp?

The manual should probably also be updated, since as Steve pointed out,
primitive-function-p does differ between compiled Lisp and C primitive. So does
also subr-native-elisp-p (which has changed name to native-comp-function-p),
which meaning seems to be the complement of primitive-function-p (regarding
functions).

May I suggest to update the manual to say that subr is a compiled function,
which is also more in the style of classical lisp, (see Lisp 1.5 manual). Maybe
add:

“subr”

     Either a primitive function, or a Lisp function that has been compiled by
     the native compiler.

and remove subr from "primitive"-paragraph:

“primitive”
     A function which is callable from Lisp but is actually written in
     C.  Primitives are also called “built-in functions”.   Examples
     include functions like ‘car’ and ‘append’.  In addition, all
     special forms (see below) are also considered primitives.

     Usually, a function is implemented as a primitive because it is a
     fundamental part of Lisp (e.g., ‘car’), or because it provides a
     low-level interface to operating system services, or because it
     needs to run fast.  Unlike functions defined in Lisp, primitives
     can be modified or added only by changing the C sources and
     recompiling Emacs.  See *note Writing Emacs Primitives::.


Or something in that style?

When we are at it also: what is intended usage of "subr-type" function?

(subr-type (symbol-function 'car)) => nil
(subr-type (symbol-function 'test-fn)) => nil

Passing in symbol results in error. If (subrp (symbol-function 'car)) returns t
I would expect subr-type to understand which kind of subr it is, but it says
nil. I probably misunderstand the intended usage, but is it meant to tell if it
is a primitive from C core, or compiled Lisp, or do you mean something else?

This is not very important per se for using Emacs Lisp, but I would like to
understand those properly.

>I've updated the docstring of 'subrp'.

Have you committed your updated doc string? I don't see any change in the doc
string (I just pulled the sources from Savannah), few minutes before I wrote and
sent this.

best regards
/a
________________________________
Från: Andrea Corallo <acorallo@gnu.org>
Skickat: den 15 augusti 2024 11:01
Till: Stephen Berman <stephen.berman@gmx.net>
Kopia: arthur miller <arthur.miller@live.com>; 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?

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

[-- Attachment #2: Type: text/html, Size: 29812 bytes --]

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

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 5899 bytes --]

>>> > (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

[-- Attachment #2: Type: text/html, Size: 15935 bytes --]