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

[arthur miller <arthur.miller@live.com>]

[-- 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 --]