GNU bug report logs - #69832
30.0.50; Should `subr-primitive-p` apply to special-forms?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69832 in the body.
You can then email your comments to 69832 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Should `subr-primitive-p` apply to special-forms?
Date: Sat, 16 Mar 2024 15:30:01 -0400

Package: Emacs
Version: 30.0.50


Currently (subr-primitive-p (symbol-function 'if)) returns t.
Its docstring disagrees:

    Return t if OBJECT is a built-in primitive function.

because `if` is indeed a "built-in primitive" but not a "function" (you
can't `funcall` it and it is rejected by `functionp`: it's a special
form instead).

For ELisp's type hierarchy/DAG we need a type for "a built-in primitive
which is also a function".  Originally, based on the docstring,
I thought I could use `subr-primitive`.
But it turns out that the code doesn't quite match the docstring.

I can see two ways to fix that:

- Introduce a new type, says `subr-function(-p)` which returns non-nil
  if and only if the argument is a built-in primitive *and* a function.

- Change the implementation of `subr-primitive-p` to match its docstring.

The patch below does the second (including changing the only place
I found that wants the current semantics.

Comments?  Objections?


        Stefan


diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el
index 411602ef166..3458ace1c08 100644
--- a/lisp/emacs-lisp/find-func.el
+++ b/lisp/emacs-lisp/find-func.el
@@ -552,7 +552,7 @@ find-function-library
     (cons function
           (cond
            ((autoloadp def) (nth 1 def))
-           ((subr-primitive-p def)
+           ((or (subr-primitive-p def) (special-form-p def))
             (if lisp-only
                 (error "%s is a built-in function" function))
             (help-C-file-name def 'subr))
diff --git a/lisp/subr.el b/lisp/subr.el
index 38a3f6edb34..f403369f534 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -315,7 +315,8 @@ subr-primitive-p
   "Return t if OBJECT is a built-in primitive function."
   (declare (side-effect-free error-free))
   (and (subrp object)
-       (not (subr-native-elisp-p object))))
+       (not (or (subr-native-elisp-p object)
+                (special-form-p object)))))
 
 (defsubst xor (cond1 cond2)
   "Return the boolean exclusive-or of COND1 and COND2.

Message #8 received at 69832 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 69832 <at> debbugs.gnu.org
Subject: Re: bug#69832: 30.0.50;
 Should `subr-primitive-p` apply to special-forms?
Date: Sat, 16 Mar 2024 21:45:19 +0200

> Cc: monnier <at> iro.umontreal.ca
> Date: Sat, 16 Mar 2024 15:30:01 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Currently (subr-primitive-p (symbol-function 'if)) returns t.
> Its docstring disagrees:
> 
>     Return t if OBJECT is a built-in primitive function.
> 
> because `if` is indeed a "built-in primitive" but not a "function" (you
> can't `funcall` it and it is rejected by `functionp`: it's a special
> form instead).
> 
> For ELisp's type hierarchy/DAG we need a type for "a built-in primitive
> which is also a function".  Originally, based on the docstring,
> I thought I could use `subr-primitive`.
> But it turns out that the code doesn't quite match the docstring.
> 
> I can see two ways to fix that:
> 
> - Introduce a new type, says `subr-function(-p)` which returns non-nil
>   if and only if the argument is a built-in primitive *and* a function.
> 
> - Change the implementation of `subr-primitive-p` to match its docstring.
> 
> The patch below does the second (including changing the only place
> I found that wants the current semantics.
> 
> Comments?  Objections?

Why take the path of a breaking change instead of the non-breaking
alternative?

Message #11 received at 69832 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69832 <at> debbugs.gnu.org
Subject: Re: bug#69832: 30.0.50; Should `subr-primitive-p` apply to
 special-forms?
Date: Sat, 16 Mar 2024 15:58:09 -0400

>> I can see two ways to fix that:
>> 
>> - Introduce a new type, says `subr-function(-p)` which returns non-nil
>>   if and only if the argument is a built-in primitive *and* a function.
>> 
>> - Change the implementation of `subr-primitive-p` to match its docstring.
>> 
>> The patch below does the second (including changing the only place
>> I found that wants the current semantics.
>> 
>> Comments?  Objections?
>
> Why take the path of a breaking change instead of the non-breaking
> alternative?

- It can be considered as a bug fix (to make the code match its doc).

- If we introduce `subr-function-p`, then `subr-primitive-p` is only
  "useful" at one place any more, and we can trivially rewrite the code to
  avoid it, so we could get rid of it.

- These functions are used very rarely, the majority is in core files,
  and the rest is mostly used to generate human-facing descriptions
  so the risk of breakage is low and the kind of breakage is likely to
  have a low impact.


        Stefan

Message #14 received at 69832 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 69832 <at> debbugs.gnu.org
Subject: Re: bug#69832: 30.0.50; Should `subr-primitive-p` apply to
 special-forms?
Date: Sat, 16 Mar 2024 22:17:25 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 69832 <at> debbugs.gnu.org
> Date: Sat, 16 Mar 2024 15:58:09 -0400
> 
> > Why take the path of a breaking change instead of the non-breaking
> > alternative?
> 
> - It can be considered as a bug fix (to make the code match its doc).

Or we could fix its doc string to be more accurate, and match what the
code does.

> - If we introduce `subr-function-p`, then `subr-primitive-p` is only
>   "useful" at one place any more, and we can trivially rewrite the code to
>   avoid it, so we could get rid of it.

I don't see why we should get rid of subr-primitive-p.  We can leave
it alone, used in that single place where it's useful, and let 3rd
party packages use it if they want.  And we can then use the new
function where that is needed.

> - These functions are used very rarely, the majority is in core files,
>   and the rest is mostly used to generate human-facing descriptions
>   so the risk of breakage is low and the kind of breakage is likely to
>   have a low impact.

Yes, but I've heard these famous last words one or two times too
many...

Message #17 received at 69832 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69832 <at> debbugs.gnu.org
Subject: Re: bug#69832: 30.0.50; Should `subr-primitive-p` apply to
 special-forms?
Date: Sat, 16 Mar 2024 19:08:56 -0400

>> - If we introduce `subr-function-p`, then `subr-primitive-p` is only
>>   "useful" at one place any more, and we can trivially rewrite the code to
>>   avoid it, so we could get rid of it.
> I don't see why we should get rid of subr-primitive-p.

Because there's no point keeping it if all its users could just as well
use `subr-function-p` or `subr-native-elisp-p` instead.

The information provided by the current semantics of `subr-primitive-p`
is "the source code was written in C", and that kind of information is
extremely rarely useful because ELisp code can't really act on that
information.  The only counter example is indeed when that ELisp code is
trying to jump to the source code.

> We can leave it alone, used in that single place where it's useful,
> and let 3rd party packages use it if they want.

It'll mostly lead to 3rd party users either wondering which one they
should use, or picking one arbitrarily without knowing the consequences.
Choice is good when the various alternatives have each their own
strengths and weaknesses, but here it's just extra complexity with no benefit.

If we introduce `subr-function-p` then we should mark `sur-primitive-p`
as obsolete.  And the only thing we gained in the process is churn (it
won't avoid regressions because the rare few users will likely just
blindly replace the old one with the new one).

>> - These functions are used very rarely, the majority is in core files,
>>   and the rest is mostly used to generate human-facing descriptions
>>   so the risk of breakage is low and the kind of breakage is likely to
>>   have a low impact.
> Yes, but I've heard these famous last words one or two times too
> many...

We make backward incompatible changes all the time in Emacs, and the
vast majority of them turns out fine.

I searched for `subr-primitive-p` in Emacs, GNU ELPA, NonGNU ELPA, and
Melpa before making my suggestion.


        Stefan

Message #20 received at 69832 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 69832 <at> debbugs.gnu.org
Subject: Re: bug#69832: 30.0.50; Should `subr-primitive-p` apply to
 special-forms?
Date: Sun, 17 Mar 2024 08:01:38 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 69832 <at> debbugs.gnu.org
> Date: Sat, 16 Mar 2024 19:08:56 -0400
> 
> >> - If we introduce `subr-function-p`, then `subr-primitive-p` is only
> >>   "useful" at one place any more, and we can trivially rewrite the code to
> >>   avoid it, so we could get rid of it.
> > I don't see why we should get rid of subr-primitive-p.
> 
> Because there's no point keeping it if all its users could just as well
> use `subr-function-p` or `subr-native-elisp-p` instead.
> 
> The information provided by the current semantics of `subr-primitive-p`
> is "the source code was written in C", and that kind of information is
> extremely rarely useful because ELisp code can't really act on that
> information.  The only counter example is indeed when that ELisp code is
> trying to jump to the source code.
> 
> > We can leave it alone, used in that single place where it's useful,
> > and let 3rd party packages use it if they want.
> 
> It'll mostly lead to 3rd party users either wondering which one they
> should use, or picking one arbitrarily without knowing the consequences.
> Choice is good when the various alternatives have each their own
> strengths and weaknesses, but here it's just extra complexity with no benefit.
> 
> If we introduce `subr-function-p` then we should mark `sur-primitive-p`
> as obsolete.  And the only thing we gained in the process is churn (it
> won't avoid regressions because the rare few users will likely just
> blindly replace the old one with the new one).
> 
> >> - These functions are used very rarely, the majority is in core files,
> >>   and the rest is mostly used to generate human-facing descriptions
> >>   so the risk of breakage is low and the kind of breakage is likely to
> >>   have a low impact.
> > Yes, but I've heard these famous last words one or two times too
> > many...
> 
> We make backward incompatible changes all the time in Emacs, and the
> vast majority of them turns out fine.
> 
> I searched for `subr-primitive-p` in Emacs, GNU ELPA, NonGNU ELPA, and
> Melpa before making my suggestion.

Well, you asked for opinions, and here you have mine.  I stand by it.

Message #25 received at 69832-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69832-done <at> debbugs.gnu.org
Subject: Re: bug#69832: 30.0.50; Should `subr-primitive-p` apply to
 special-forms?
Date: Sun, 17 Mar 2024 17:03:59 -0400

> Well, you asked for opinions, and here you have mine.  I stand by it.

Fair enough.  I'll go with a new `primitive-function-p`, then.
I'll include it in the `cl-type-of` patch(es).


        Stefan

Previous Next

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