Subject: bug#66615: closed (Re: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 19 Oct 2023 12:04:02 +0000

Your bug report

#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
66615: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66615
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery
From: Andrea Corallo <[email-masked]>
To: Stefan Monnier <[email-masked]>
Cc: [email-masked], Mattias Engdegård <[email-masked]>
Date: Thu, 19 Oct 2023 08:02:42 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Andrea Corallo <[email-masked]> writes:

> [re-replaying as for some reason our responses didn't reach the list]
>
> Stefan Monnier <[email-masked]> writes:
>
>>> My question is, why do we consider 'number-or-marker' in the first place
>>> a type if we support the or syntax in `cl-typep' like
>>> (cl-typep 3 '(or marker number)) ?
>>
>> I'm not sure I can give a good answer in general, but I can tell you
>> some reasons that explain some of what we see:
>>
>> - There is a `number-or-marker-p` primitive and `cl-typep` doesn't know
>>   how to use it for `(or number marker)`.
>
> Well we could just remove 'number-or-marker-p' 😃
>
>> - method specializers (currently) can't be `(or number marker)` but can be
>>   `number-or-marker`.
>
> Okay this is more difficult to fix... :/
>
>>> I'd like to fix this inconsistency in order to progress with my
>>> development, originally I worked out the attached patch but I now
>>> suspect that (unless there's a specific reason) we should just remove
>>> 'number-or-marker' as a type entirely instead.
>>
>> I'd lean towards keeping it :-)
>
> I see your point, actually my main drive is to make the situation more
> coherent so I'm unblocked in the first place, just the method
> specializer functionality is a blocker for removing 'number-or-marker'.
>
> I think adding 'number-or-marker' where missing is probably the best
> solution for now.

Okay with a567faf4c2b I added 'number-or-marker' where it was missing.
Closing this, happy to reopen if necessary.

Thanks!

  Andrea

Subject: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery
From: Andrea Corallo <[email-masked]>
To: <[email-masked]>
Cc: Mattias Engdegård <[email-masked]>, Stefan Monnier <[email-masked]>
Date: Wed, 18 Oct 2023 13:59:21 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello all,

while performing some development I noticed that 'number-or-marker' is
mentioned as a type in 'cl--typeof-types'.

Unfortunatelly its entry is missing in 'cl-deftype-satisfies' (see
cl-macs.el:3469).

My question is, why do we consider 'number-or-marker' in the first place
a type if we support the or syntax in `cl-typep' like
(cl-typep 3 '(or marker number)) ?

I'd like to fix this inconsistency in order to progress with my
development, originally I worked out the attached patch but I now
suspect that (unless there's a specific reason) we should just remove
'number-or-marker' as a type entirely instead.

WDYT? Thanks

  Andrea

PS also I think we have a similar issue/question with
'integer-or-marker'.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>From 05d85f19e51c15df8824df8e8608784ec79b37cf Mon Sep 17 00:00:00 2001
From: Andrea Corallo <[email-masked]>
Date: Wed, 18 Oct 2023 16:10:08 +0200
Subject: [PATCH] Add two missing 'number-or-marker' entries to the cl
 machinery.

Assuming 'number-or-marker' is a type (as present multiple times in
cl--typeof-types) adding some missing entries for coherency.

* lisp/emacs-lisp/cl-preloaded.el (cl--typeof-types): Add
'number-or-marker' as supertype of 'number' in the 'float' branch.

* lisp/emacs-lisp/cl-macs.el (cl-deftype-satisfies): Add
'number-or-marker'.

* test/lisp/emacs-lisp/comp-cstr-tests.el (comp-cstr-typespec-tests-alist):
Update test.

* test/src/comp-tests.el (comp-tests-type-spec-tests): Update two testes.
---
 lisp/emacs-lisp/cl-macs.el              | 3 ++-
 lisp/emacs-lisp/cl-preloaded.el         | 4 ++--
 test/lisp/emacs-lisp/comp-cstr-tests.el | 2 +-
 test/src/comp-tests.el                  | 4 ++--
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 8025a64f1bf..722d561b9f4 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -3502,7 +3502,8 @@ cl--macroexp-fboundp
                  (symbol	. symbolp)
                  (vector	. vectorp)
                  (window	. windowp)
-                 ;; FIXME: Do we really want to consider this a type?
+                 ;; FIXME: Do we really want to consider these types?
+                 (number-or-marker . number-or-marker-p)
                  (integer-or-marker . integer-or-marker-p)
                  ))
   (put type 'cl-deftype-satisfies pred))
diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el
index 676326980aa..96e288db7d5 100644
--- a/lisp/emacs-lisp/cl-preloaded.el
+++ b/lisp/emacs-lisp/cl-preloaded.el
@@ -58,8 +58,8 @@ cl--typeof-types
     ;; Markers aren't `numberp', yet they are accepted wherever integers are
     ;; accepted, pretty much.
     (marker number-or-marker atom)
-    (overlay atom) (float number atom) (window-configuration atom)
-    (process atom) (window atom)
+    (overlay atom) (float number number-or-marker atom)
+    (window-configuration atom) (process atom) (window atom)
     ;; FIXME: We'd want to put `function' here, but that's only true
     ;; for those `subr's which aren't special forms!
     (subr atom)
diff --git a/test/lisp/emacs-lisp/comp-cstr-tests.el b/test/lisp/emacs-lisp/comp-cstr-tests.el
index a4f282fcfef..d2f552af6fa 100644
--- a/test/lisp/emacs-lisp/comp-cstr-tests.el
+++ b/test/lisp/emacs-lisp/comp-cstr-tests.el
@@ -191,7 +191,7 @@
       ;; 74
       ((and boolean (or number marker)) . nil)
       ;; 75
-      ((and atom (or number marker)) . (or marker number))
+      ((and atom (or number marker)) . number-or-marker)
       ;; 76
       ((and symbol (or number marker)) . nil)
       ;; 77
diff --git a/test/src/comp-tests.el b/test/src/comp-tests.el
index 4444ab61219..31871bb2eec 100644
--- a/test/src/comp-tests.el
+++ b/test/src/comp-tests.el
@@ -977,7 +977,7 @@ comp-tests-check-ret-type-spec
          (if (= x y)
              x
            'foo))
-       '(or (member foo) marker number))
+       '(or (member foo) marker-or-number))
 
       ;; 14
       ((defun comp-tests-ret-type-spec-f (x)
@@ -1117,7 +1117,7 @@ comp-tests-check-ret-type-spec
       ((defun comp-tests-ret-type-spec-f (x)
 	 (when (> x 1.0)
 	   x))
-       '(or null marker number))
+       '(or null number-or-marker))
 
       ;; 36
       ((defun comp-tests-ret-type-spec-f (x y)
-- 
2.25.1