>> On Tue, 13 Aug 2024 18:00:12 +0000 arthur miller >> 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 Skickat: den 15 augusti 2024 11:01 Till: Stephen Berman Kopia: arthur miller ; 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 writes: > On Tue, 13 Aug 2024 18:00:12 +0000 arthur miller 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