unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
@ 2024-03-16 19:30 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-16 19:45 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-16 19:30 UTC (permalink / raw)
  To: 69832; +Cc: monnier

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.






^ permalink raw reply related	[flat|nested] 7+ messages in thread

* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
  2024-03-16 19:30 bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms? Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-16 19:45 ` Eli Zaretskii
  2024-03-16 19:58   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-03-16 19:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 69832

> Cc: monnier@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@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?





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
  2024-03-16 19:45 ` Eli Zaretskii
@ 2024-03-16 19:58   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-16 20:17     ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-16 19:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 69832

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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
  2024-03-16 19:58   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-16 20:17     ` Eli Zaretskii
  2024-03-16 23:08       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-03-16 20:17 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 69832

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 69832@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...





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
  2024-03-16 20:17     ` Eli Zaretskii
@ 2024-03-16 23:08       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-17  6:01         ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-16 23:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 69832

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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
  2024-03-16 23:08       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-17  6:01         ` Eli Zaretskii
  2024-03-17 21:03           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-03-17  6:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 69832

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 69832@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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
  2024-03-17  6:01         ` Eli Zaretskii
@ 2024-03-17 21:03           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-17 21:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 69832-done

> 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






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-03-17 21:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-16 19:30 bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms? Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-16 19:45 ` Eli Zaretskii
2024-03-16 19:58   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-16 20:17     ` Eli Zaretskii
2024-03-16 23:08       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-17  6:01         ` Eli Zaretskii
2024-03-17 21:03           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).