GNU bug report logs - #56648
29.0.50; Need for `compiled-function-p`

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Tue, 19 Jul 2022 20:44:02 UTC

Severity: wishlist

Found in version 29.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56648 <at> debbugs.gnu.org
Subject: bug#56648: 29.0.50; Need for `compiled-function-p`
Date: Sat, 23 Jul 2022 20:27:37 -0400
Lars Ingebrigtsen [2022-07-23 06:30:03] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> 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, ...).
>
> Makes sense to me.  <bikeshed>But since the use case is "is this one of
> those slow source code functions?" then why not reverse the logic and
> call it `uncompiled-function-p'?</bikeshed>

I can think of 2 reasons:

A) `compiled-function-p` exists in Common-Lisp.

B) It would require redoing some of the work I've just done because

       (uncompiled-function-p X) != (not (compiled-function-p X))

   when X is not a function, so it's not just a simple search&replace.


-- Stefan





This bug report was last modified 2 years and 336 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.