bug#56648: closed (29.0.50; Need for `compiled-function-p`)

[GNU bug Tracking System]

Your message dated Sun, 14 Aug 2022 12:30:20 -0400
with message-id <jwvzgg6n6eh.fsf-monnier+emacs@gnu.org>
and subject line Re: bug#56648: 29.0.50; Need for `compiled-function-p`
has caused the debbugs.gnu.org bug report #56648,
regarding 29.0.50; Need for `compiled-function-p`
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
56648: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56648
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 29.0.50; Need for `compiled-function-p`
>
>
>
>
> Date: 
>
> Tue, 19 Jul 2022 16:43:27 -0400
>
>
>
>
> Package: Emacs
> Version: 29.0.50
>
>
> I think we need something like `compiled-function-p`, i.e. a function
> which will return non-nil for both byte-code and native-code functions.
> Its definition would be
>
>     (defun compiled-function-p (obj)
>       "<Appropriate doc here>"
>       (or (byte-code-function-p obj)
>           (subr-native-elisp-p obj)))
>
> This is because `byte-code-function-p` shouldn't be changed to return
> non-nil for native-code functions (both because it would break a lot of
> code and because the name would be too confusing), but several uses of
> `byte-code-function-p` actually want to know "is this an (inefficient)
> source code function or not" (e.g. in unidata-gen.el,
> loadup.el, bytecomp.el, ...).
>
>
>         Stefan
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#56648: 29.0.50; Need for `compiled-function-p`
>
>
>
>
> Date: 
>
> Sun, 14 Aug 2022 12:30:20 -0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
>
>
>
>
> Pushed to `master` with some tweaks and doc,
>
>
>         Stefan
>
>
>
> --- End Message ---