--- Begin Message ---
|
Subject: |
30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery |
|
Date: |
Wed, 18 Oct 2023 13:59:21 -0400 |
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 <acorallo@gnu.org>
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery |
|
Date: |
Thu, 19 Oct 2023 08:02:42 -0400 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Andrea Corallo <acorallo@gnu.org> writes:
> [re-replaying as for some reason our responses didn't reach the list]
>
> Stefan Monnier <monnier@iro.umontreal.ca> 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
--- End Message ---