X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 11 Apr 2025 07:16:01 +0000
Resent-Message-ID: <handler.77725.B.174435570816495 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 77725 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.174435570816495
(code B ref -1); Fri, 11 Apr 2025 07:16:01 +0000
Received: (at submit) by debbugs.gnu.org; 11 Apr 2025 07:15:08 +0000
Received: from localhost ([127.0.0.1]:48406 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u38bS-0004DG-LI
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 03:15:08 -0400
Received: from lists.gnu.org ([2001:470:142::17]:60348)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u38bP-0003wx-Sv
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 03:15:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <da_vid@HIDDEN>) id 1u38bJ-0003rO-5q
for bug-gnu-emacs@HIDDEN; Fri, 11 Apr 2025 03:14:57 -0400
Received: from smtp-30.smtpout.orange.fr ([80.12.242.30]
helo=smtp.smtpout.orange.fr)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <da_vid@HIDDEN>) id 1u38bG-0005SS-7Q
for bug-gnu-emacs@HIDDEN; Fri, 11 Apr 2025 03:14:56 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 38b3u04qE724L38b6uxRDI; Fri, 11 Apr 2025 09:14:45 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744355685;
bh=2UI7M3qLfQE5LbfHoG1pFjvgVsqiCTDgOReIVK8khWo=;
h=Message-ID:Date:MIME-Version:To:From:Subject;
b=DlseKPD6Q8EBYzCfgBJE7FXzd/8CbIHS8dfQc6WwrWKIq3tqOGvApEgWgQZ6BBXRu
yRE092/fdwN28uhqigpcPRas/9G45Qp1BC0IuT7Yi7X93uk7KfftQa4lZnCSoosBEu
xozZ/MZFOIJJ+C8fYXafzAuHbJqFDChNsCT6FNcbjVOcl7nBgkYNePqhPy9az2+Pq8
WahzECAkjHiOweXoYhtG+QxJy8bWqDq3IMfqyl0omTdTxKpsFOFaLn0TipOW4cTmqY
75q3x0qFZlmWWRJVoeZ8Ncg/sPJe0Mx3+IjuO+AApfvlWV5quC+iEKWpuOA6UA1Sv0
sk32cmoA28KuA==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 11 Apr 2025 09:14:45 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------n1eQXsc1ZT8h0XgHFf6i8M60"
Message-ID: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
Date: Fri, 11 Apr 2025 09:14:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
Received-SPF: pass client-ip=80.12.242.30; envelope-from=da_vid@HIDDEN;
helo=smtp.smtpout.orange.fr
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
This is a multi-part message in MIME format.
--------------n1eQXsc1ZT8h0XgHFf6i8M60
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hello
In the cl-generic library, the implementation of the
`cl-generic-generalizers' "typeof" method, used to dispatch
"normal types", mentions in a FIXME on line 1367: "Add support for
other "types" accepted by `cl-typep' such as `character', `face',
`keyword', ...?".
As part of some other works, I created the attached "gtype" library,
which complements `cl-deftype' so that such defined types are also
recognized as argument types for dispatching generic function methods.
Here is a quick example of use:
(defgtype face nil ()
"A face type."
'(satisfies facep))
(gtype-of 'default)
=> face
(cl-type-of 'default)
=> symbol
(cl-defmethod my-add-face ((text string) (face face))
(propertize text 'face face))
=> my-add-face
(my-add-face "text" 'bold)
=> #("text" 0 4 (face bold))
(my-add-face "text" 'bad-face)
=> No applicable method: add-face, "text", bad-face
I've been using this library successfully in some of my code, and was
wondering if it could help add this functionality to Emacs. My goal
is not to include this library, but to use it as a starting point for
further reflection on this subject.
My library is relatively concise and adopts a design similar to that
used for built-in types. The new types (which I call "gtypes") are
instances of the structure `gtype-class', derived from `cl--class',
just as built-in types are instances of the structure `built-in-class'
also derived from `cl--class'. gtypes thus benefits from the existing
infrastructure used for other types. I also chose to have a separate
"generalizer" for gtypes. I'm not sure if it would be desirable to
extend the existing generalizer "typof" to support such types.
I would therefore be interested in hearing more expert opinions on
my implementation and whether it could help add this functionality to
cl-generic, if it makes sense.
Thank you for your time.
--------------n1eQXsc1ZT8h0XgHFf6i8M60
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el"
Content-Disposition: attachment; filename="gtype.el"
Content-Transfer-Encoding: base64
Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g
bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u
Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50
YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw
cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg
cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl
ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m
IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg
UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs
b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv
bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k
cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg
ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg
dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KOzsK
OzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1h
Y3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rp
b24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9mIGFuIG9iamVjdC4KOzsKOzsgLSBgcmVtZ3R5
cGUnLCBhIG1hY3JvIHRoYXQgcmVtb3ZlcyBhIGd0eXBlLgo7Owo7OyBBIHRyaXZpYWwgZXhh
bXBsZToKOzsKOzsgKGRlZmd0eXBlIG5lZ2F0aXZlIG5pbCAoKQo7OyAgICJBIG5lZ2F0aXZl
IG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlzZmllcyBtaW51c3ApKSkKOzsKOzsg
KGRlZmd0eXBlIHplcm8gbmlsICgpCjs7ICAgIkEgemVybyBudW1iZXIiCjs7ICAgJyhhbmQg
bnVtYmVyIChzYXRpc2ZpZXMgemVyb3ApKSkKOzsKOzsgKGRlZmd0eXBlIHBvc2l0aXZlIG5p
bCAoKQo7OyAgICJBIHBvc2l0aXZlIG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlz
ZmllcyBwbHVzcCkpKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBuZWdh
dGl2ZSkpCjs7ICAgKGZvcm1hdCAibmVnYXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7IChj
bC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHplcm8pKQo7OyAgIChmb3JtYXQgInplcm8g
bnVtYmVyLCAlcyIgbikpCjs7Cjs7IChjbC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHBv
c2l0aXZlKSkKOzsgICAoZm9ybWF0ICJwb3NpdGl2ZSBudW1iZXIsICVzIiBuKSkKOzsKOzsg
KHRlc3QtbnVtYmVyIC0xMjMuMCkKOzsgPT4gIm5lZ2F0aXZlIG51bWJlciwgLTEyMy4wIgo7
OyAodGVzdC1udW1iZXIgKGFicyAtMTIzLjApKQo7OyA9PiAicG9zaXRpdmUgbnVtYmVyLCAx
MjMuMCIKOzsgKHRlc3QtbnVtYmVyIChyb3VuZCAwLjAwMDAwMDAwMDAwMSkpCjs7ID0+ICJ6
ZXJvIG51bWJlciwgMCIKOzsKOzsgUGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnM6Cjs7Cjs7
IFRoZSBjcml0aWNhbCBwb2ludCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpcyB0
aGUgZnVuY3Rpb24KOzsgYGd0eXBlLW9mJyB3aGljaCBzZXF1ZW50aWFsbHkgdHJpZXMgYWxs
IGtub3duIGd0eXBlcywgZnJvbSB0aGUgbW9zdAo7OyBzcGVjaWZpYyB0byB0aGUgbW9zdCBn
ZW5lcmFsLCB1bnRpbCB0aGUgbW9zdCBzcGVjaWZpYyBndHlwZSB0aGF0Cjs7IGFwcGxpZXMg
dG8gYSBnaXZlbiBvYmplY3QgaXMgZm91bmQuICBUaGVyZWZvcmUsIHRoZSBtYXhpbXVtIHRp
bWUgdG8KOzsgZmluZCBhbiBvYmplY3QncyB0eXBlIGRpcmVjdGx5IGRlcGVuZHMgb24gdGhl
IG51bWJlciBvZiBndHlwZXMgdG8KOzsgdHJ5LiAgSXMgdGhlcmUgYSBiZXR0ZXIgc29sdXRp
b24/ICBBbnl3YXksIGFzc3VtaW5nIHRoYXQgZWFjaAo7OyBzaW5nbGUgdGVzdCB0byBrbm93
IHdoZXRoZXIgYW4gb2JqZWN0IGlzIG9mIGEgZ2l2ZW4gZ3R5cGUgaXMKOzsgcmVhc29uYWJs
eSBmYXN0LCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBzZWVtcwo7
OyBhY2NlcHRhYmxlIChiYXNlZCBvbiB0aGUgdHJpdmlhbCBleGFtcGxlIGFib3ZlLCBhdHRl
bXB0aW5nIDEsMDAwCjs7IGd0eXBlIGNoZWNrcyB0YWtlcyBhYm91dCBoYWxmIGEgbWlsbGlz
ZWNvbmQgb24gbXkgc2V0dXApLgo7OwoKOzs7IENvZGU6Cjs7CihyZXF1aXJlICdjbC1saWIp
CgooY2wtZGVmc3RydWN0CiAgICAoZ3R5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNs
YXNzKQogICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAo
OmNvbnN0cnVjdG9yIGd0eXBlLS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAgICAobmFt
ZSBkb2NzdHJpbmcgcGFyZW50LXR5cGVzCiAgICAgICAgICAgICAgICAgICAgICAgICAmYXV4
IChwYXJlbnRzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAodHlwZSkKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChvciAoY2wtLWZpbmQtY2xhc3MgdHlwZSkKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIlVua25vd24gdHlwZTog
JVMiIHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlw
ZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3IgZ3R5
cGVzLiIpCgooZGVmdmFyIGd0eXBlLS1saXN0IG5pbAogICJMaXN0IG9mIGFsbCB0aGUgZ3R5
cGVzIGN1cnJlbnRseSBkZWZpbmVkLiIpCgooZGVmaW5lLWlubGluZSBndHlwZS1wIChvYmpl
Y3QpCiAgIlJldHVybiBub24tbmlsIGlmIHRoZSB0eXBlIG9mIE9CSkVDVCBpcyBhIGd0eXBl
LiIKICAoaW5saW5lLWxldGV2YWxzIChvYmplY3QpCiAgICAoaW5saW5lLXF1b3RlCiAgICAg
KGFuZCAoc3ltYm9scCAsb2JqZWN0KQogICAgICAgICAgKGVxICh0eXBlLW9mIChjbC0tZmlu
ZC1jbGFzcyAsb2JqZWN0KSkgJ2d0eXBlLWNsYXNzKSkpKSkKCihkZWZtYWNybyBndHlwZS0t
YWxscGFyZW50cyAobmFtZSkKICAiUmV0dXJuIGFsbCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBO
QU1FLgpOQU1FIG11c3QgYmUgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlwZS4iCiAgOzsg
VG8gc2F2ZSBjYWxscyB0byBgY2wtLWNsYXNzLWFsbHBhcmVudHMnIGNhY2hlIHBhcmVudHMg
b2YgZ3R5cGVzCiAgOzsgKHBvc3NpYmx5IGJ1aWx0aW4gdHlwZXMpLiBgZ3R5cGUtLXJlZ2lz
dGVyJyB0YWtlcyBjYXJlIG9mCiAgOzsgY2xlYXJpbmcgY2FjaGVkIHZhbHVlcyBpZiBhIGd0
eXBlIGlzIHJlZGVmaW5lZDsgYW5kIHRoZXJlIHNob3VsZAogIDs7IGJlIG5vdGhpbmcgdG8g
ZG8gZm9yIGJ1aWx0aW4gdHlwZXMgd2hpY2ggc2hvdWxkIG5vdCBjaGFuZ2UuCiAgYChvciAo
Z2V0ICxuYW1lICdndHlwZS0tYWxscGFyZW50cykKICAgICAgIChwdXQgLG5hbWUgJ2d0eXBl
LS1hbGxwYXJlbnRzCiAgICAgICAgICAgIChjbC0tY2xhc3MtYWxscGFyZW50cyAoY2wtLWZp
bmQtY2xhc3MgLG5hbWUpKSkpKQoKKGRlZnVuIGd0eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdl
dCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2Vu
dGluZyBhIHR5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgog
IChhbmQgKHN5bWJvbHAgbmFtZSkKICAgICAgIChsZXQgKChjbGFzcyAoY2wtLWZpbmQtY2xh
c3MgbmFtZSkpKQogICAgICAgICAoaWYgY2xhc3MKICAgICAgICAgICAgIChpZiAobWVtcSAo
dHlwZS1vZiBjbGFzcykgJyhndHlwZS1jbGFzcyBidWlsdC1pbi1jbGFzcykpCiAgICAgICAg
ICAgICAgICAgOzsgQ2FjaGUgZ3R5cGUgKGFuZCBidWlsdGluIHR5cGUpIHBhcmVudHMuCiAg
ICAgICAgICAgICAgICAgKGd0eXBlLS1hbGxwYXJlbnRzIG5hbWUpCiAgICAgICAgICAgICAg
IDs7IERvbid0IGNhY2hlIG90aGVyIHR5cGUgcGFyZW50cy4KICAgICAgICAgICAgICAgKGNs
LS1jbGFzcy1hbGxwYXJlbnRzIGNsYXNzKSkpKSkpCgooZGVmdW4gZ3R5cGUtY2hpbGRyZW4g
KG5hbWUpCiAgIkdldCBjaGlsZHJlbiBvZiB0aGUgZ3R5cGUgd2l0aCBOQU1FLgpOQU1FIGlz
IGEgc3ltYm9sIHJlcHJlc2VudGluZyBhIGd0eXBlLgpSZXR1cm4gYSBwb3NzaWJseSBlbXB0
eSBsaXN0IG9mIHR5cGVzLiIKICAobGV0IChjaGlsZHJlbikKICAgIChkb2xpc3QgKGVsdCBn
dHlwZS0tbGlzdCkKICAgICAgKG9yIChlcSBuYW1lIGVsdCkKICAgICAgICAgIChpZiAobWVt
cSBuYW1lIChndHlwZS0tYWxscGFyZW50cyBlbHQpKQogICAgICAgICAgICAgIChwdXNoIGVs
dCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkKCihkZWZ1biBndHlwZS0tcmVnaXN0ZXIg
KG5hbWUgJm9wdGlvbmFsIHBhcmVudHMgYXJncykKICAiUmVnaXN0ZXIgYSBndHlwZSB3aXRo
IE5BTUUgYW5kIFBBUkVOVFMuCkFSR1MgYXJlIHRob3NlIHRoYXQgd2lsbCBiZSBwYXNzZWQg
dG8gYGNsLWRlZnR5cGUnLiIKICA7OyBBdCB0aGlzIHBvaW50IE5BTUUgbXVzdCBiZSBhIGRl
ZmluZWQgdHlwZS4KICAoY2wtYXNzZXJ0IChnZXQgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVy
KSBuaWwKICAgICAgICAgICAgICJVbmtub3duIHR5cGUgJVMiIG5hbWUpCiAgKGxldCAoKGNs
YXNzIChjbC0tZmluZC1jbGFzcyBuYW1lKSkKICAgICAgICAocmVnZWQgKG1lbXEgbmFtZSBn
dHlwZS0tbGlzdCkpKQogICAgKGlmIChudWxsIGNsYXNzKQogICAgICAgIChjbC1hc3NlcnQg
KG51bGwgcmVnZWQpIG5pbCAiRXhpc3RpbmcgdHlwZSBub3QgcmVnaXN0ZXJlZCIpCiAgICAg
IChjbC1hc3NlcnQgcmVnZWQgbmlsICJOZXcgdHlwZSBhbHJlYWR5IHJlZ2lzdGVyZWQiKQog
ICAgICAoY2wtYXNzZXJ0IChlcSAodHlwZS1vZiBjbGFzcykgJ2d0eXBlLWNsYXNzKSBuaWwK
ICAgICAgICAgICAgICAgICAiVHlwZSBpcyBpbiBhbm90aGVyIGNsYXNzOiAlUyIgKHR5cGUt
b2YgY2xhc3MpKSkKICAgIChvciAobGlzdHAgcGFyZW50cykgKHNldHEgcGFyZW50cyAobGlz
dCBwYXJlbnRzKSkpCiAgICAoY2wtYXNzZXJ0IChudWxsIChtZW1xIG5hbWUgcGFyZW50cykp
IG5pbAogICAgICAgICAgICAgICAiVHlwZSBpcyBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykK
ICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9yIGZvciBOQU1FLCB3aXRoIFBBUkVOVFMg
YW5kIHRoZSBkb2NzdHJpbmcKICAgIDs7IHBvc3NpYmx5IHByZXNlbnQgaW4gQVJHUy4KICAg
IChsZXQgKChkb2NzdHJpbmcgKGNhYXIgKG1hY3JvZXhwLXBhcnNlLWJvZHkgKGNkciBhcmdz
KSkpKSkKICAgICAgKG9yIChzdHJpbmdwIGRvY3N0cmluZykgKHNldHEgZG9jc3RyaW5nIG5p
bCkpCiAgICAgIChzZXRmIChjbC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAoZ3R5
cGUtLWNsYXNzLW1ha2UgbmFtZSBkb2NzdHJpbmcgcGFyZW50cykpKQogICAgKGlmIGNsYXNz
CiAgICAgICAgOzsgQ2xlYXIgdGhlIGNhY2hlZCB2YWx1ZSBvZiBwYXJlbnRzIGZvciBlYWNo
IGNoaWxkcmVuIG9mIGEKICAgICAgICA7OyBtb2RpZmllZCBndHlwZS4KICAgICAgICAoZG9s
aXN0IChjIChndHlwZS1jaGlsZHJlbiBuYW1lKSkKICAgICAgICAgIChjbC1yZW1wcm9wIGMg
J2d0eXBlLS1hbGxwYXJlbnRzKSkKICAgICAgOzsgUmVjb3JkIHRoZSBuZXcgdHlwZS4KICAg
ICAgKHB1c2ggbmFtZSBndHlwZS0tbGlzdCkpCiAgICA7OyBUbyBmaW5kIHRoZSBtb3N0IHBv
c3NpYmxlIHNwZWNpZmljIGd0eXBlIG9mIGFuIG9iamVjdCwgdGhlIG1vc3QKICAgIDs7IHNw
ZWNpZmljIHR5cGVzIG11c3QgYmUgdHJpZWQgYmVmb3JlIHRoZSBtb3JlIGdlbmVyYWwgdHlw
ZXMuIFRoZQogICAgOzsgbGlzdCBvZiBndHlwZXMgaXMgdGhlcmVmb3JlIHNvcnRlZCBhY2Nv
cmRpbmdseSwgYXNzdW1pbmcgZWFjaAogICAgOzsgdHlwZSBpcyBkaXN0aW5jdCBhbmQgdGhh
dCB0aGUgbW9yZSBwYXJlbnRzIGEgdHlwZSBoYXMsIHRoZSBtb3JlCiAgICA7OyBzcGVjaWZp
YyBpdCBpcy4KICAgIChzZXRxIGd0eXBlLS1saXN0CiAgICAgICAgICAoc29ydCBndHlwZS0t
bGlzdAogICAgICAgICAgICAgICAgOmtleSAobGFtYmRhICh0eXBlKSAobGVuZ3RoIChndHlw
ZS0tYWxscGFyZW50cyB0eXBlKSkpCiAgICAgICAgICAgICAgICA6bGVzc3AgIyc+PQogICAg
ICAgICAgICAgICAgOmluLXBsYWNlIHQpKQogICAgbmFtZSkpCgooZGVmdW4gZ3R5cGUtLXVu
cmVnaXN0ZXIgKG5hbWUpCiAgIlVucmVnaXN0ZXIgdGhlIGd0eXBlIHdpdGggTkFNRS4iCiAg
KGNsLWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogIChjbC1hc3NlcnQg
KG51bGwgKGd0eXBlLWNoaWxkcmVuIG5hbWUpKSB0ICJUeXBlIGhhcyBjaGlsZHJlbjogJVMi
KQogIChjbC1yZW1wcm9wIG5hbWUgJ2d0eXBlLS1hbGxwYXJlbnRzKQogIChjbC1yZW1wcm9w
IG5hbWUgJ2NsLS1jbGFzcykKICAoY2wtcmVtcHJvcCBuYW1lICdjbC1kZWZ0eXBlLWhhbmRs
ZXIpCiAgKHNldHEgZ3R5cGUtLWxpc3QgKGRlbHEgbmFtZSBndHlwZS0tbGlzdCkpCiAgbmls
KQoKOzs7IyMjYXV0b2xvYWQKKGRlZm1hY3JvIGRlZmd0eXBlIChuYW1lICZvcHRpb25hbCBw
YXJlbnRzICZyZXN0IGFyZ3MpCiAgIkRlZmluZSBOQU1FIGFzIGEgZ3R5cGUgdGhhdCBpbmhl
cml0cyBmcm9tIFBBUkVOVFMuCklmIGEgZ3R5cGUgd2l0aCBOQU1FIGFscmVhZHkgZXhpc3Rz
LCByZXBsYWNlIGl0LgoKTkFNRSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5n
IGEgZ3R5cGUuCgpPcHRpb25hbCBhcmd1bWVudCBQQVJFTlRTIGlzIGVpdGhlciBhbiB1bnF1
b3RlZCBzeW1ib2wgb3IgbGlzdCBvZgpzeW1ib2xzIG90aGVyIHRoYW4gTkFNRSByZXByZXNl
bnRpbmcgdHlwZXMgcGFyZW50cyBvZiBOQU1FLgpQQVJFTlRTIG5pbCBvciBvbWl0dGVkIG1l
YW5zIHRoYXQgTkFNRSBpcyBhIHJvb3QgdHlwZS4KCkFsc28gcGFzcyBOQU1FIGFuZCBBUkdT
IHRvIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgTkFNRSBhcyBhIG5ldyBkYXRhCnR5cGUuIgog
IChkZWNsYXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1zdHJpbmcgNCkgKGluZGVudCAz
KSkKICBgKHByb2duCiAgICAgKGNsLWRlZnR5cGUgLG5hbWUgLEBhcmdzKQogICAgIChndHlw
ZS0tcmVnaXN0ZXIgJyxuYW1lICcscGFyZW50cyAnLGFyZ3MpKSkKCihkZWZtYWNybyByZW1n
dHlwZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4g
dW5xdW90ZWQgc3ltYm9sIHJlcHJlc2VudGluZyBhIGd0eXBlLgpTaWduYWwgYW4gZXJyb3Ig
aWYgb3RoZXIgZ3R5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICBgKGd0eXBlLS11bnJlZ2lz
dGVyICcsbmFtZSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3Mg
cmVjdXJzaW9uIGluICdndHlwZS1vZicuCihkZWZ2YXIgZ3R5cGUtLW9iamVjdCAobWFrZS1z
eW1ib2wgInZvaWQiKSkKKGRlZnZhciBndHlwZS0tdHlwZSBuaWwpCgooZGVmdW4gZ3R5cGUt
b2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSBtb3N0IHNwZWNpZmljIHBvc3NpYmxlIGd0eXBl
IG9mIE9CSkVDVCwgb3IgbmlsIGlmIG5vbmUuIgogIDs7IElnbm9yZSByZWN1cnNpdmUgY2Fs
bCBvbiB0aGUgc2FtZSBPQkpFQ1QsIHdoaWNoIGNhbiBsZWdpdGltYXRlbHkKICA7OyBvY2N1
ciB3aGVuLCBmb3IgZXhhbXBsZSwgYSBwYXJlbnQgdHlwZSBpcyBpbnZlc3RpZ2F0aW5nIHdo
ZXRoZXIKICA7OyBhbiBvYmplY3QncyB0eXBlIGlzIHRoYXQgb2Ygb25lIG9mIGl0cyBjaGls
ZHJlbi4KICAodW5sZXNzIChlcSBvYmplY3QgZ3R5cGUtLW9iamVjdCkKICAgIChsZXQgKChn
dHlwZS0tb2JqZWN0IG9iamVjdCkKICAgICAgICAgICh0eXBlcyBndHlwZS0tbGlzdCkKICAg
ICAgICAgIGZvdW5kKQogICAgICA7OyBUcnkgZWFjaCBndHlwZSwgZnJvbSBtb3N0IHNwZWNp
ZmljIHRvIGxlYXN0IHNwZWNpZmljLCB1bnRpbAogICAgICA7OyBvbmUgaXMgZm91bmQgYXMg
dGhlIG1vc3Qgc3BlY2lmaWMgcG9zc2libGUgZ3R5cGUgb2YgT0JKRUNULgogICAgICAod2hp
bGUgKGFuZCAobm90IGZvdW5kKSB0eXBlcykKICAgICAgICAobGV0ICgoZ3R5cGUtLXR5cGUg
KGNhciB0eXBlcykpKQogICAgICAgICAgKGlmIChjbC10eXBlcCBvYmplY3QgZ3R5cGUtLXR5
cGUpCiAgICAgICAgICAgICAgKHNldHEgZm91bmQgZ3R5cGUtLXR5cGUpCiAgICAgICAgICAg
IChzZXRxIHR5cGVzIChjZHIgdHlwZXMpKSkpKQogICAgICBmb3VuZCkpKQoKOzs7IE1ldGhv
ZCBkaXNwYXRjaGluZwo7OwooZGVmdW4gZ3R5cGUtLXNwZWNpYWxpemVycyAodGFnICZyZXN0
IF8pCiAgIklmIFRBRyBpcyBhIGd0eXBlLCByZXR1cm4gaXRzIHNwZWNpYWxpemVycy4iCiAg
KGlmIChndHlwZS1wIHRhZykgKGd0eXBlLS1hbGxwYXJlbnRzIHRhZykpKQoKKGNsLWdlbmVy
aWMtZGVmaW5lLWdlbmVyYWxpemVyIGd0eXBlLS1nZW5lcmFsaXplcgogIDEwCiAgKGxhbWJk
YSAob2JqICZyZXN0IF8pIGAoZ3R5cGUtb2YgLG9iaikpCiAgIydndHlwZS0tc3BlY2lhbGl6
ZXJzKQoKKGNsLWRlZm1ldGhvZCBjbC1nZW5lcmljLWdlbmVyYWxpemVycyA6ZXh0cmEgImd0
eXBlLW9mIiAodHlwZSkKICAiU3VwcG9ydCBmb3IgZGlzcGF0Y2ggb24gZ3R5cGVzLiIKICAo
aWYgKGd0eXBlLXAgdHlwZSkKICAgICAgKGxpc3QgZ3R5cGUtLWdlbmVyYWxpemVyKQogICAg
KGNsLWNhbGwtbmV4dC1tZXRob2QpKSkKCihwcm92aWRlICdndHlwZSkKCjs7OyBndHlwZS5l
bCBlbmRzIGhlcmUK
--------------n1eQXsc1ZT8h0XgHFf6i8M60--
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: David Ponce <da_vid@HIDDEN> Subject: bug#77725: Acknowledgement (31.0.50; Add support for types accepted by `cl-typep' to cl-generic?) Message-ID: <handler.77725.B.174435570816495.ack <at> debbugs.gnu.org> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> X-Gnu-PR-Message: ack 77725 X-Gnu-PR-Package: emacs Reply-To: 77725 <at> debbugs.gnu.org Date: Fri, 11 Apr 2025 07:16:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 77725 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 77725: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77725 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 11 Apr 2025 08:38:01 +0000
Resent-Message-ID: <handler.77725.B77725.174436067710292 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174436067710292
(code B ref 77725); Fri, 11 Apr 2025 08:38:01 +0000
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 08:37:57 +0000
Received: from localhost ([127.0.0.1]:48625 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u39td-0002fw-0u
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 04:37:57 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50592)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u39ta-0002fe-2p
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 04:37:54 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1u39tT-0000ay-ND; Fri, 11 Apr 2025 04:37:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=X78ael6JLBIlHxw3SCMO1KkSDUVuJxhisIHg6i7pLZ4=; b=XYNivL5nk8bb
Du5Bfihzz1Hcun/JTMmQMSu0EOKv196XzBNOI/uarvZU9cNLW9+r4DW83f5ZnAX7zDg5VhPWWm4Ut
SsiHnZOBfbfrLcmGbjMYE2XtFwu74JM50YNBrGI5T6TvywCB+JWY2QLW2GdIHjS9Kp1OsoOGA16/C
PSnQGcc+pabiofqJauDMOfqD1aPP9flVzy9go7cVpiOzlVlWOaWP7CfHrqUVCMv3hJKu+0N3tgtYd
OngDoK3dFqcvOu0smscVbss2W+dweN3Kx7ELlI/Vt+mY/t3cDaDenEKZkhvzmcvOmfCDOJQgxQrKl
N4R5jtlTekD/CoTyqzVk+Q==;
Date: Fri, 11 Apr 2025 11:37:38 +0300
Message-Id: <868qo7ozzh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
(bug-gnu-emacs@HIDDEN)
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Fri, 11 Apr 2025 09:14:41 +0200
> From: David Ponce via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> In the cl-generic library, the implementation of the
> `cl-generic-generalizers' "typeof" method, used to dispatch
> "normal types", mentions in a FIXME on line 1367: "Add support for
> other "types" accepted by `cl-typep' such as `character', `face',
> `keyword', ...?".
>
> As part of some other works, I created the attached "gtype" library,
> which complements `cl-deftype' so that such defined types are also
> recognized as argument types for dispatching generic function methods.
> Here is a quick example of use:
>
> (defgtype face nil ()
> "A face type."
> '(satisfies facep))
>
> (gtype-of 'default)
> => face
> (cl-type-of 'default)
> => symbol
>
> (cl-defmethod my-add-face ((text string) (face face))
> (propertize text 'face face))
> => my-add-face
>
> (my-add-face "text" 'bold)
> => #("text" 0 4 (face bold))
>
> (my-add-face "text" 'bad-face)
> => No applicable method: add-face, "text", bad-face
>
> I've been using this library successfully in some of my code, and was
> wondering if it could help add this functionality to Emacs. My goal
> is not to include this library, but to use it as a starting point for
> further reflection on this subject.
>
> My library is relatively concise and adopts a design similar to that
> used for built-in types. The new types (which I call "gtypes") are
> instances of the structure `gtype-class', derived from `cl--class',
> just as built-in types are instances of the structure `built-in-class'
> also derived from `cl--class'. gtypes thus benefits from the existing
> infrastructure used for other types. I also chose to have a separate
> "generalizer" for gtypes. I'm not sure if it would be desirable to
> extend the existing generalizer "typof" to support such types.
>
> I would therefore be interested in hearing more expert opinions on
> my implementation and whether it could help add this functionality to
> cl-generic, if it makes sense.
Thanks, adding Stefan to the discussion.
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 11 Apr 2025 13:42:02 +0000
Resent-Message-ID: <handler.77725.B77725.174437891225837 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Eli Zaretskii <eliz@HIDDEN>
Cc: David Ponce <da_vid@HIDDEN>, 77725 <at> debbugs.gnu.org
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174437891225837
(code B ref 77725); Fri, 11 Apr 2025 13:42:02 +0000
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 13:41:52 +0000
Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3Edj-0006if-Gm
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 09:41:51 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65131)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u3Edh-0006iJ-Iu
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 09:41:50 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B8749801CC;
Fri, 11 Apr 2025 09:41:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744378901;
bh=aLrlpaqrdo3szFgPr5+3BgiajoyN0PqHkYE9mLN7rDY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=eyke12sbTDv3I7bVpCeuU+4lDGZSf95t98hNYuEC/g7tTrT7CZ02EhZJ06BFHQrEA
KVAABz94w3+WkHCtlZlCWgoOgR6WZgJiSpJ5VPX9T4agTa7SZcJJ7LMSL0um2cx/ch
Wh5cL+hkUtDo3s4KzSiwutk//pPIMSfNSUp4Wz1tb9df9lWRHFJSmuyd0GPjmrhZcW
zlEbM7j4bJ4rKkLi5WcDCdx3hh2mMgDF5T8n1fuVySXo6tjsaTMUjX1g43kgzxfrUt
esEpO5AhJXW1n8PKuAiw5qGzjDglyNXdaGMeZgNWjWFUkyUzJAGIFV1HmmdAt7aGlE
kMs/tmnt42UbA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D6C2E80599;
Fri, 11 Apr 2025 09:41:41 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AD62E120346;
Fri, 11 Apr 2025 09:41:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <868qo7ozzh.fsf@HIDDEN>
Message-ID: <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN>
Date: Fri, 11 Apr 2025 09:41:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.354 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Hi David,
>> As part of some other works, I created the attached "gtype" library,
>> which complements `cl-deftype' so that such defined types are also
>> recognized as argument types for dispatching generic function methods.
>> Here is a quick example of use:
>>
>> (defgtype face nil ()
>> "A face type."
>> '(satisfies facep))
>>
>> (gtype-of 'default)
>> => face
>> (cl-type-of 'default)
>> => symbol
>>
>> (cl-defmethod my-add-face ((text string) (face face))
>> (propertize text 'face face))
>> => my-add-face
Nice.
>> I've been using this library successfully in some of my code, and was
>> wondering if it could help add this functionality to Emacs. My goal
>> is not to include this library, but to use it as a starting point for
>> further reflection on this subject.
The problem with adding new generalizers is to make sure they interact
correctly with others. If you allow `satisfies` kind of definitions,
then it's easy to end up with situations where one of your new types is
neither a subtype (aka sub-specializer) nor a supertype
(super-specializer) of an existing type (specializer).
Let's take `function` defined as `(satisfies functionp)` is an example.
(functionp '(lambda () 1))
=> t
(type-of '(lambda a))
=> cons
this suggests (satisfies functionp) should be a subtype of `cons`, but
that is clearly wrong because
(functionp (lambda () 1))
=> t
(consp (lambda () 1))
=> nil
The type-dispatch code wants *one* value (generalizer) to lookup the
hash-table where it will find the corresponding effective method.
That one value should be "the most specific" generalizer among the
generalizers currently used for that generic function.
Now a `gtype-of` called `g-function` built from `(satisfies functionp)`
will be sometimes more specific and sometimes less specific than
`type-of`, so there is no correct PRIORITY to indicate to
`cl-generic-define-generalizer`: we'll end up with dispatch errors if
a generic function has a method for both `g-function` and for `cons`.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 11 Apr 2025 15:05:02 +0000
Resent-Message-ID: <handler.77725.B77725.174438386417346 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174438386417346
(code B ref 77725); Fri, 11 Apr 2025 15:05:02 +0000
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 15:04:24 +0000
Received: from localhost ([127.0.0.1]:51202 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3Fvc-0004Vi-46
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 11:04:24 -0400
Received: from smtp-29.smtpout.orange.fr ([80.12.242.29]:50725
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u3FvW-0004V7-O0
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 11:04:21 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 3FvOu4XDK724L3FvSuQZmY; Fri, 11 Apr 2025 17:04:16 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744383856;
bh=c9KZDmLNFIGaaw/k0e8rChzd4Scd8yW6K5hacRM5uZE=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=qYV8GdC2tVCb+4AKMQUo+/iTNt1tX85CRWje87Gj/vKVOJoKSM1XXUvREfxO9z+Y4
S/1Y8BOb33D1P5dzFw7SIdbeB/HrgmapxhUQC5t2lPNWajlsUMrEhLlleYa5TnvN3b
OcHi4mgi335n/E/nZbfKsllfXw0BYwUGpYdgto1JZD1lCNLWjovGk4Hxz0qmC29eyS
DGtyhnlkM27uxOVTEG1JrdI9/f8P9UniCLN7EaeFazDF9+My15lRBaDo3SN2anQSvK
li0LBsv4k75oyrgDFW+rurZrZWtxpvR4dAu5kpsoUfy+g0OOmEMC+hvhRiDOsb+Cof
cU+wEwbktnnmg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 11 Apr 2025 17:04:16 +0200
X-ME-IP: 90.112.40.65
Message-ID: <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
Date: Fri, 11 Apr 2025 17:04:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-11 15:41, Stefan Monnier wrote:
> Hi David,
>
>>> As part of some other works, I created the attached "gtype" library,
>>> which complements `cl-deftype' so that such defined types are also
>>> recognized as argument types for dispatching generic function methods.
>>> Here is a quick example of use:
>>>
>>> (defgtype face nil ()
>>> "A face type."
>>> '(satisfies facep))
>>>
>>> (gtype-of 'default)
>>> => face
>>> (cl-type-of 'default)
>>> => symbol
>>>
>>> (cl-defmethod my-add-face ((text string) (face face))
>>> (propertize text 'face face))
>>> => my-add-face
>
> Nice.
>
>>> I've been using this library successfully in some of my code, and was
>>> wondering if it could help add this functionality to Emacs. My goal
>>> is not to include this library, but to use it as a starting point for
>>> further reflection on this subject.
>
> The problem with adding new generalizers is to make sure they interact
> correctly with others. If you allow `satisfies` kind of definitions,
> then it's easy to end up with situations where one of your new types is
> neither a subtype (aka sub-specializer) nor a supertype
> (super-specializer) of an existing type (specializer).
>
> Let's take `function` defined as `(satisfies functionp)` is an example.
>
> (functionp '(lambda () 1))
> => t
> (type-of '(lambda a))
> => cons
>
> this suggests (satisfies functionp) should be a subtype of `cons`, but
> that is clearly wrong because
>
> (functionp (lambda () 1))
> => t
> (consp (lambda () 1))
> => nil
>
> The type-dispatch code wants *one* value (generalizer) to lookup the
> hash-table where it will find the corresponding effective method.
> That one value should be "the most specific" generalizer among the
> generalizers currently used for that generic function.
>
> Now a `gtype-of` called `g-function` built from `(satisfies functionp)`
> will be sometimes more specific and sometimes less specific than
> `type-of`, so there is no correct PRIORITY to indicate to
> `cl-generic-define-generalizer`: we'll end up with dispatch errors if
> a generic function has a method for both `g-function` and for `cons`.
>
>
> Stefan
>
Hi Stefan,
Thank you very much for your feedback!
Your remarks make sense, for sure.
Does this mean that for a `cl-deftype'-like generalizer to work
correctly, it must be part of the "typof" generalizer?
In other words, that a function like `gtype-of' should fall back to
`cl-type-of' when there is no corresponding gtype for an object?
Or am I missing something? --- Sorry, I only started studying
cl-generic relatively recently, and I probably don't understand
all its intricacies ;-)
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 11 Apr 2025 16:27:01 +0000
Resent-Message-ID: <handler.77725.B77725.17443887784465 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17443887784465
(code B ref 77725); Fri, 11 Apr 2025 16:27:01 +0000
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 16:26:18 +0000
Received: from localhost ([127.0.0.1]:51471 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3HCs-00019w-1N
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 12:26:18 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13865)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u3HCq-00019h-8a
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 12:26:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 48E9D801CC;
Fri, 11 Apr 2025 12:26:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744388763;
bh=QkUTtgbokRJaxYtUqIgLaDHF0CO7A5VqS7cLdC/eL6k=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=JHLQ3zmd+ezW+6m0IJuVg9XTyhx9Urhct2oHSKKTd004fYH2qCPYXOucz9MtHvT1W
HR4brIcUm+K7sBgsFH8MSGP+4RZaTbYiVXXAYj+wSwAPqfsdqfu9i9JcDAmUEXe3LA
LrxE+7qUFHp3/AZ64Cghffe8IqpNzqmzGyBXPzz8KpPr2FEz6Nv94lldOVvRAxbt0g
4O9CqQL6wAerIG6fDDMOJ/RNVH/OxKXdVl6z0afBrrmd9LIpaWegfr2khZbE3U8dIv
GHptrVnivCZoGpSMwYjusPYogZm2Bw/3PR4pKbOrfBkRZMIxCc59LpidK/w5RLX6yq
xKURWrQ1dh72g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9A8C9804C9;
Fri, 11 Apr 2025 12:26:03 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7B1031202BB;
Fri, 11 Apr 2025 12:26:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
Message-ID: <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
Date: Fri, 11 Apr 2025 12:26:05 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.172 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Does this mean that for a `cl-deftype'-like generalizer to work
> correctly, it must be part of the "typof" generalizer?
No, but it needs to be either always more precise or always less precise
than `type-of`.
IOW, either:
(eql (gtypeof-generalizer A) (gtypeof-generalizer B))
IMPLIES ((eql (gtypeof-generalizer A) nil)
OR (eql (cl-type-of A) (cl-type-of B)))
or the reverse. That's a current limitation in the cl-generic system.
One way to solve this is to use a generalizer that returns either nil or
a pair containing both the `gtype-of` and the `cl-type-of`, so it's
trivially always more precise than `cl-type-of`. But beware: these
things are compared with `eql` so you need to "uniquify" them with
a sort of hashconsing scheme.
BTW if you do
(defgtype cons-car-foo nil ()
"A cons with a `foo' car."
`(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
(defgtype cons-cdr-foo nil ()
"A cons with a `foo' cdr."
`(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
what's the `(gtype-of '(foo . foo))` ?
> Or am I missing something? --- Sorry, I only started studying
> cl-generic relatively recently, and I probably don't understand
> all its intricacies ;-)
Yeah, it's unsatisfactorily intricate, indeed. It's designed first and
foremost to keep the dispatch "simple and reasonable fast", at the cost
of making `cl-generic-define-generalizer` a very sharp tool. =F0=9F=99=82
I have recently been thinking about how to make it more reliable (which
would also make it more flexible/powerful, allowing the definition of
both `and` and `or` specializers). I have some vague idea, but there's
no code at all yet, and it might come with some non-trivial tradeoffs
(e.g. preloading the byte-compiler).
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 13 Apr 2025 14:47:01 +0000
Resent-Message-ID: <handler.77725.B77725.17445555891106 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17445555891106
(code B ref 77725); Sun, 13 Apr 2025 14:47:01 +0000
Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 14:46:29 +0000
Received: from localhost ([127.0.0.1]:43332 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3ybM-0000Hl-CQ
for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 10:46:29 -0400
Received: from smtp-24.smtpout.orange.fr ([80.12.242.24]:44683
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u3ybH-0000HX-Pi
for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 10:46:26 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 3ya2uKxz6RaJG3ya5uQlEl; Sun, 13 Apr 2025 16:45:11 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744555511;
bh=qpk8zId1r1RTtMKitxDoBxUozhQqWAkBI5QVPGt3DsU=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=la3GsbS8HQi0mon4L4hbTrUVs6TPYvQ1N/OT9QVZHFt+UGkudca/1iGGDt+IIj/nd
2O19SEdIMo6lIwGp2LY/f29MkIWAPJ+NceQ++I3dODO/QOIUg8kOuQP7QjBa8fCu+I
TvmX+StfSg7/JUTc1l696C7TQlABjl2rg1Fe8P/mbHw/hSQ+qIPYXo36JlTIwzUoGT
z/O0ZzOzZhT3CFJxzKntF9mjFbHfyPDrK138UnbUy022pd4ufxLBJOX0BjkY53T49S
r1+IGKKwmoAqYDUzDAf+TMkwhfJzLVpGe5x9Vx+LijywzNP3EH1x4gOSdC7mc9qPyF
47A/V/mwG2B0g==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sun, 13 Apr 2025 16:45:11 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------K7ayjXP8dGQosZr0arxKGOQ6"
Message-ID: <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
Date: Sun, 13 Apr 2025 16:45:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------K7ayjXP8dGQosZr0arxKGOQ6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Stefan,
Sorry for this late answer. It took me a while to take it all in ;-)
On 2025-04-11 18:26, Stefan Monnier wrote:
>> Does this mean that for a `cl-deftype'-like generalizer to work
>> correctly, it must be part of the "typof" generalizer?
>
> No, but it needs to be either always more precise or always less precise
> than `type-of`.
>
> IOW, either:
>
> (eql (gtypeof-generalizer A) (gtypeof-generalizer B))
> IMPLIES ((eql (gtypeof-generalizer A) nil)
> OR (eql (cl-type-of A) (cl-type-of B)))
>
> or the reverse. That's a current limitation in the cl-generic system.
>
> One way to solve this is to use a generalizer that returns either nil or
> a pair containing both the `gtype-of` and the `cl-type-of`, so it's
> trivially always more precise than `cl-type-of`. But beware: these
> things are compared with `eql` so you need to "uniquify" them with
> a sort of hashconsing scheme.
I am not sure to understand this point.
AFAICS, gtypes always take precedence over other types. So, provided
I correctly understand your point, the gtype generalizer is more precise
than `type-of`.
For instance, if you define an icon type like this:
(defgtype icon nil ()
"Builtin icon type."
'(and symbol (satisfies iconp)))
(gtype-of 'button)
=> icon
(cl-type-of 'button)
=> symbol
So you cannot have two methods with the same name, one to handle the
symbol type, and one to handle the icon type. I agree, it is a
limitation. Is this your point?
I wonder if in practice it is really inconvenient, and worth the
trouble of complicate more the implementation? Isn't it clearer to
use different methods for icons and symbols? Aren't these types
fundamentally different, and isn't the fact that an icon is a symbol
just an implementation choice?
>
> BTW if you do
>
> (defgtype cons-car-foo nil ()
> "A cons with a `foo' car."
> `(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
>
> (defgtype cons-cdr-foo nil ()
> "A cons with a `foo' cdr."
> `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
>
> what's the `(gtype-of '(foo . foo))` ?
Regarding this point, perhaps it would be possible to use an heuristic
like: "in case of conflict, the last defined type is chosen as the
most specific"?
I implemented this idea in gtype (attached) to compute the gtype
precedence list, by using a topologic sort with a tie-breaker to
decide which gtype will be the most specific between two candidates
that cannot be separated otherwise. It should be easy to implement
different heuristics by providing different tie-breakers.
With your example, if you define `cons-cdr-foo' after `cons-car-foo':
(gtype-of '(foo . foo))
=> cons-cdr-foo
And, if you define `cons-car-foo' after `cons-cdr-foo':
(gtype-of '(foo . foo))
=> cons-car-foo
To avoid inconsistent method dispatching, the order of gtypes does not
change if you eval again the definition of an existing gtype. But the
order will change if you first remove the gtype, then define it again.
>> Or am I missing something? --- Sorry, I only started studying
>> cl-generic relatively recently, and I probably don't understand
>> all its intricacies ;-)
>
> Yeah, it's unsatisfactorily intricate, indeed. It's designed first and
> foremost to keep the dispatch "simple and reasonable fast", at the cost
> of making `cl-generic-define-generalizer` a very sharp tool. 🙂
>
> I have recently been thinking about how to make it more reliable (which
> would also make it more flexible/powerful, allowing the definition of
> both `and` and `or` specializers). I have some vague idea, but there's
> no code at all yet, and it might come with some non-trivial tradeoffs
> (e.g. preloading the byte-compiler).
I can't wait to see this :-)
Thanks for your patience!
--------------K7ayjXP8dGQosZr0arxKGOQ6
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el"
Content-Disposition: attachment; filename="gtype.el"
Content-Transfer-Encoding: base64
Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g
bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u
Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50
YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw
cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg
cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl
ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m
IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg
UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs
b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv
bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k
cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg
ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg
dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KOzsK
OzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1h
Y3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rp
b24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9mIGFuIG9iamVjdC4KOzsKOzsgLSBgcmVtZ3R5
cGUnLCBhIG1hY3JvIHRoYXQgcmVtb3ZlcyBhIGd0eXBlLgo7Owo7OyBBIHRyaXZpYWwgZXhh
bXBsZToKOzsKOzsgKGRlZmd0eXBlIG5lZ2F0aXZlIG5pbCAoKQo7OyAgICJBIG5lZ2F0aXZl
IG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlzZmllcyBtaW51c3ApKSkKOzsKOzsg
KGRlZmd0eXBlIHplcm8gbmlsICgpCjs7ICAgIkEgemVybyBudW1iZXIiCjs7ICAgJyhhbmQg
bnVtYmVyIChzYXRpc2ZpZXMgemVyb3ApKSkKOzsKOzsgKGRlZmd0eXBlIHBvc2l0aXZlIG5p
bCAoKQo7OyAgICJBIHBvc2l0aXZlIG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlz
ZmllcyBwbHVzcCkpKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBuZWdh
dGl2ZSkpCjs7ICAgKGZvcm1hdCAibmVnYXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7IChj
bC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHplcm8pKQo7OyAgIChmb3JtYXQgInplcm8g
bnVtYmVyLCAlcyIgbikpCjs7Cjs7IChjbC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHBv
c2l0aXZlKSkKOzsgICAoZm9ybWF0ICJwb3NpdGl2ZSBudW1iZXIsICVzIiBuKSkKOzsKOzsg
KHRlc3QtbnVtYmVyIC0xMjMuMCkKOzsgPT4gIm5lZ2F0aXZlIG51bWJlciwgLTEyMy4wIgo7
OyAodGVzdC1udW1iZXIgKGFicyAtMTIzLjApKQo7OyA9PiAicG9zaXRpdmUgbnVtYmVyLCAx
MjMuMCIKOzsgKHRlc3QtbnVtYmVyIChyb3VuZCAwLjAwMDAwMDAwMDAwMSkpCjs7ID0+ICJ6
ZXJvIG51bWJlciwgMCIKOzsKOzsgUGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnM6Cjs7Cjs7
IFRoZSBjcml0aWNhbCBwb2ludCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpcyB0
aGUgZnVuY3Rpb24KOzsgYGd0eXBlLW9mJyB3aGljaCBzZXF1ZW50aWFsbHkgdHJpZXMgYWxs
IGtub3duIGd0eXBlcywgZnJvbSB0aGUgbW9zdAo7OyBzcGVjaWZpYyB0byB0aGUgbW9zdCBn
ZW5lcmFsLCB1bnRpbCB0aGUgbW9zdCBzcGVjaWZpYyBndHlwZSB0aGF0Cjs7IGFwcGxpZXMg
dG8gYSBnaXZlbiBvYmplY3QgaXMgZm91bmQuICBUaGVyZWZvcmUsIHRoZSBtYXhpbXVtIHRp
bWUgdG8KOzsgZmluZCBhbiBvYmplY3QncyB0eXBlIGRpcmVjdGx5IGRlcGVuZHMgb24gdGhl
IG51bWJlciBvZiBndHlwZXMgdG8KOzsgdHJ5LiAgSXMgdGhlcmUgYSBiZXR0ZXIgc29sdXRp
b24/ICBBbnl3YXksIGFzc3VtaW5nIHRoYXQgZWFjaAo7OyBzaW5nbGUgdGVzdCB0byBrbm93
IHdoZXRoZXIgYW4gb2JqZWN0IGlzIG9mIGEgZ2l2ZW4gZ3R5cGUgaXMKOzsgcmVhc29uYWJs
eSBmYXN0LCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBzZWVtcwo7
OyBhY2NlcHRhYmxlIChiYXNlZCBvbiB0aGUgdHJpdmlhbCBleGFtcGxlIGFib3ZlLCBhdHRl
bXB0aW5nIDEsMDAwCjs7IGd0eXBlIGNoZWNrcyB0YWtlcyBhYm91dCBoYWxmIGEgbWlsbGlz
ZWNvbmQgb24gbXkgc2V0dXApLgo7OwoKOzs7IENvZGU6Cjs7CihyZXF1aXJlICdjbC1saWIp
CihldmFsLXdoZW4tY29tcGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5k
LWNsYXNzLgoKKGRlZnZhciBndHlwZS0tbGlzdCBuaWwKICAiUHJlY2VkZW5jZSBsaXN0IG9m
IHRoZSBkZWZpbmVkIGd0eXBlcy4iKQooZGVmdmFyIGd0eXBlLS1zZXFuIDAKICAiU2VxdWVu
Y2UgbnVtYmVyIG9mIGRlZmluZWQgZ3R5cGVzLiIpCgooZGVmaW5lLWlubGluZSBndHlwZS1w
IChvYmplY3QpCiAgIlJldHVybiBub24tbmlsIGlmIHRoZSB0eXBlIG9mIE9CSkVDVCBpcyBh
IGd0eXBlLiIKICAoaW5saW5lLWxldGV2YWxzIChvYmplY3QpCiAgICAoaW5saW5lLXF1b3Rl
CiAgICAgKGFuZCAoc3ltYm9scCAsb2JqZWN0KQogICAgICAgICAgKGVxICh0eXBlLW9mIChj
bC0tZmluZC1jbGFzcyAsb2JqZWN0KSkgJ2d0eXBlLWNsYXNzKSkpKSkKCihkZWZpbmUtaW5s
aW5lIGd0eXBlLS1hbGxwYXJlbnRzIChuYW1lKQogICJSZXR1cm4gYWxsIHBhcmVudHMgb2Yg
dHlwZSB3aXRoIE5BTUUuCk5BTUUgbXVzdCBiZSBhIHN5bWJvbCByZXByZXNlbnRpbmcgYSB0
eXBlLiIKICA7OyBUbyBzYXZlIGNhbGxzIHRvIGBjbC0tY2xhc3MtYWxscGFyZW50cycgY2Fj
aGUgcGFyZW50cyBvZiBndHlwZXMKICA7OyAocG9zc2libHkgYnVpbHRpbiB0eXBlcykuIGBn
dHlwZS0tcmVnaXN0ZXInIHRha2VzIGNhcmUgb2YKICA7OyBjbGVhcmluZyBjYWNoZWQgdmFs
dWVzIGlmIGEgZ3R5cGUgaXMgcmVkZWZpbmVkOyBhbmQgdGhlcmUgc2hvdWxkCiAgOzsgYmUg
bm90aGluZyB0byBkbyBmb3IgYnVpbHRpbiB0eXBlcyB3aGljaCBzaG91bGQgbm90IGNoYW5n
ZS4KICAoaW5saW5lLXF1b3RlCiAgIChvciAoZ2V0ICxuYW1lICdndHlwZS0tYWxscGFyZW50
cykKICAgICAgIChwdXQgLG5hbWUgJ2d0eXBlLS1hbGxwYXJlbnRzCiAgICAgICAgICAgIChj
bC0tY2xhc3MtYWxscGFyZW50cyAoY2wtLWZpbmQtY2xhc3MgLG5hbWUpKSkpKSkKCihjbC1k
ZWZzdHJ1Y3QKICAgIChndHlwZS1jbGFzcwogICAgICg6aW5jbHVkZSBjbC0tY2xhc3MpCiAg
ICAgKDpub2lubGluZSB0KQogICAgICg6Y29uc3RydWN0b3IgbmlsKQogICAgICg6Y29uc3Ry
dWN0b3IgZ3R5cGUtLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAgICAg
ICAgICAgICAgICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5
cGVzCiAgICAgICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAgICAg
ICAgICAgICAgIChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAo
dHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2wtY2hlY2stdHlwZSB0eXBl
IChzYXRpc2ZpZXMgZ3R5cGUtcCkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNs
LS1maW5kLWNsYXNzIHR5cGUpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQt
dHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3Ig
Z3R5cGVzLiIpCgooZGVmdW4gZ3R5cGUtcGFyZW50cyAobmFtZSkKICAiR2V0IHBhcmVudHMg
b2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlw
ZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNsLWNoZWNr
LXR5cGUgbmFtZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogIChndHlwZS0tYWxscGFyZW50cyBu
YW1lKSkKCihkZWZ1biBndHlwZS1jaGlsZHJlbiAobmFtZSkKICAiR2V0IGNoaWxkcmVuIG9m
IHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEg
Z3R5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgogIChjbC1j
aGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBndHlwZS1wKSkKICAobGV0IChjaGlsZHJlbikK
ICAgIChkb2xpc3QgKGVsdCBndHlwZS0tbGlzdCkKICAgICAgKG9yIChlcSBuYW1lIGVsdCkK
ICAgICAgICAgIChpZiAobWVtcSBuYW1lIChndHlwZS0tYWxscGFyZW50cyBlbHQpKQogICAg
ICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkKCihkZWZ1
biBndHlwZS0tdGllLWJyZWFrZXIgKG0xIG0yKQogICJSZXR1cm4gdGhlIGxlc3Mgc3BlY2lm
aWMgb2YgdHdvIG1pbi1lbGVtZW50cyBNMSBhbmQgTTIuClRoYXQgaXMsIHRoZSBtaW4tZWxl
bWVudCBmaXJzdCBwdXNoZWQgaW4gdGhlIGd0eXBlIHByZWNlZGVuY2UgbGlzdCwKb3JkZXJl
ZCBmcm9tIG1vc3QgdG8gbGVzcyBzcGVjaWZpYyB0eXBlcy4KSWYgTTEgYW5kIE0yIGhvbGQg
Z3R5cGVzLCBwcmVmZXIgdGhlIG9uZSB3aXRoIHRoZSBmaXJzdCBkZWZpbmVkIGd0eXBlLgpP
dGhlcndpc2UsIHByZWZlciBNMSwgdGhlIGZpcnN0IG1pbi1lbGVtZW50IGZvdW5kIGluIHRo
ZSBEQUcuIgogIChpZi1sZXQqICgoaTEgKGdldCAoY2FyIG0xKSAnZ3R5cGUtLXNlcW4pKQog
ICAgICAgICAgICAoaTIgKGdldCAoY2FyIG0yKSAnZ3R5cGUtLXNlcW4pKSkKICAgICAgKGlm
ICg8IGkxIGkyKSBtMSBtMikKICAgIG0xKSkKCihkZWZ1biBndHlwZS0tdG9wb2xvZ2ljLXNv
cnQgKGdyYXBoICZvcHRpb25hbCB0aWUtYnJlYWtlcikKICAiUmV0dXJuIHRoZSB0b3BvbG9n
aWNhbGx5IHNvcnRlZCBlbGVtZW50cyBvZiBHUkFQSC4KR1JBUEggbXVzdCBiZSBhIHZhbGlk
IGRpcmVjdGVkIGFjeWNsaWMgZ3JhcGggKERBRykgYXMgYSBsaXN0IG9mCmVsZW1lbnRzIChW
aSBbVmogVmsuLi5Wbl0pIHdoaWNoIG1lYW5zIHRoYXQgVmkgZGVwZW5kcyB1cG9uIFZqLCBW
agp1cG9uIFZrLCBldGMuLCBvciBkZXBlbmRzIHVwb24gbm90aGluZy4gIFNpZ25hbCBhbiBl
cnJvciBvdGhlcndpc2UuCkVsZW1lbnRzIGFyZSBjb21wYXJlZCB1c2luZyBgZXEnLgoKSWYg
bm9uLW5pbCwgVElFLUJSRUFLRVIgbXVzdCBiZSBhIGZ1bmN0aW9uIHRoYXQgcmVjZWl2ZXMg
dGhlCnByZXZpb3VzbHkgYW5kIGxhc3QgZm91bmQgbWluLWVsZW1lbnRzKCopLCBhbmQgbXVz
dCByZXR1cm4gb25lIG9mCnRoZW0uICBJZiBUSUUtQlJFQUtFUiBpcyBuaWwgb3Igb21pdHRl
ZCwgcHJlZmVyIHRoZSBmaXJzdCBtaW4tZWxlbWVudApmb3VuZCwgaS5lLiB0aGUgb25lIHRo
YXQgYXBwZWFycyBmaXJzdCBpbiB0aGUgbmF0dXJhbCBvcmRlciBvZiB0aGUKREFHLgoKWypd
IEEgbWluLWVsZW1lbnQgaXMgYW4gZWxlbWVudCB3aXRoIG5vIHN1Y2Nlc3NvciwgbGlrZSAo
RCkuCgpTb21lIGV4YW1wbGVzOgoKICAoZ3R5cGUtLXRvcG9sb2dpYy1zb3J0IFxcPScoKEEg
QiBDKSAoQiBEKSAoQyBEKSAoRCkpKQogID0+IChBIEIgQyBEKQoKICAoZ3R5cGUtLXRvcG9s
b2dpYy1zb3J0IFxcPScoKEEgQiBDKSAoQiBEKSAoQyBEKSAoRCkpCiAgICAgICAgICAgICAg
ICAgICAgICAgICAobGFtYmRhIChfcHJldiBsYXN0KSBsYXN0KSkKICA9PiAoQSBDIEIgRCkK
CiAgKGd0eXBlLS10b3BvbG9naWMtc29ydCBcXD0nKChBIEIgQykgKEIgRCkgKEQgQikgKEQp
KSkKICA9PiBlcnJvciIKICAoZGVjbGFyZSAoc2lkZS1lZmZlY3QtZnJlZSB0KSkKICAoY2wt
bGFiZWxzICgocmVtcS1taW5pbWFsIChtIGcpCiAgICAgICAgICAgICAgICA7OyBSZW1vdmUg
bWluLWVsZW1lbnQgTSBmcm9tIEcuCiAgICAgICAgICAgICAgICAobGV0ICgobWUgKGNhciBt
KSkgcmVzdWx0KQogICAgICAgICAgICAgICAgICAoZG9saXN0IChlIChkZWxxIG0gZykpCiAg
ICAgICAgICAgICAgICAgICAgKHB1c2ggKGNvbnMgKGNhciBlKSAocmVtcSBtZSAoY2RyIGUp
KSkgcmVzdWx0KSkKICAgICAgICAgICAgICAgICAgcmVzdWx0KSkKICAgICAgICAgICAgICAo
bmV4dC1taW5pbWFsIChnKQogICAgICAgICAgICAgICAgOzsgUmV0dXJuIHRoZSBuZXh0IG1p
bi1lbGVtZW50IGZvdW5kIGluIEcuCiAgICAgICAgICAgICAgICAobGV0IChtKQogICAgICAg
ICAgICAgICAgICAoZG9saXN0IChlIGcpCiAgICAgICAgICAgICAgICAgICAgKG9yIChjZHIg
ZSkKICAgICAgICAgICAgICAgICAgICAgICAgOzsgV2hlbiB0aGVyZSBhcmUgdHdvIG1pbi1l
bGVtZW50cywgY2FsbCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgOzsgVElFLUJSRUFL
RVIgdG8gZGVjaWRlIHdoaWNoIG9uZSBpcyBtb3JlCiAgICAgICAgICAgICAgICAgICAgICAg
IDs7IHNwZWNpZmljLgogICAgICAgICAgICAgICAgICAgICAgICAoc2V0cSBtIChpZiBtIChm
dW5jYWxsIHRpZS1icmVha2VyIG0gZSkgZSkpKSkKICAgICAgICAgICAgICAgICAgbSkpKQog
ICAgKG9yIHRpZS1icmVha2VyIChzZXRxIHRpZS1icmVha2VyIChsYW1iZGEgKHByZXYgX25l
eHQpIHByZXYpKSkKICAgIChsZXQgKChnIChjb3B5LXNlcXVlbmNlIGdyYXBoKSkgdHMpCiAg
ICAgICh3aGlsZSAod2hlbi1sZXQqICgobSAobmV4dC1taW5pbWFsIGcpKSkKICAgICAgICAg
ICAgICAgKHNldHEgZyAocmVtcS1taW5pbWFsIG0gZykpCiAgICAgICAgICAgICAgIChwdXNo
IChjYXIgbSkgdHMpKSkKICAgICAgKGNsLWFzc2VydCAoZXFsIChsZW5ndGggZ3JhcGgpIChs
ZW5ndGggdHMpKSBuaWwKICAgICAgICAgICAgICAgICAiSW52YWxpZCBncmFwaCwgJVMiIHRz
KQogICAgICB0cykpKQoKKGRlZnVuIGd0eXBlLS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZy
b20gdGhlIGxpc3Qgb2YgZGVmaW5lZCBndHlwZXMuIgogIChtYXBjYXIgIydndHlwZS0tYWxs
cGFyZW50cyBndHlwZS0tbGlzdCkpCgooZGVmdW4gZ3R5cGUtLXJlZ2lzdGVyIChuYW1lICZv
cHRpb25hbCBwYXJlbnRzIGFyZ3MpCiAgIlJlZ2lzdGVyIGEgZ3R5cGUgd2l0aCBOQU1FIGFu
ZCBQQVJFTlRTLgpBUkdTIGFyZSB0aG9zZSB0aGF0IHdpbGwgYmUgcGFzc2VkIHRvIGBjbC1k
ZWZ0eXBlJy4iCiAgOzsgQXQgdGhpcyBwb2ludCBOQU1FIG11c3QgYmUgYSBkZWZpbmVkIHR5
cGUuCiAgKGNsLWFzc2VydCAoZ2V0IG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcikgbmlsCiAg
ICAgICAgICAgICAiVW5rbm93biB0eXBlICVTIiBuYW1lKQogIChsZXQgKChjbGFzcyAoY2wt
LWZpbmQtY2xhc3MgbmFtZSkpCiAgICAgICAgKHJlZ2VkIChtZW1xIG5hbWUgZ3R5cGUtLWxp
c3QpKSkKICAgIChpZiAobnVsbCBjbGFzcykKICAgICAgICAoY2wtYXNzZXJ0IChudWxsIHJl
Z2VkKSBuaWwgIkV4aXN0aW5nIHR5cGUgbm90IHJlZ2lzdGVyZWQiKQogICAgICAoY2wtYXNz
ZXJ0IHJlZ2VkIG5pbCAiTmV3IHR5cGUgYWxyZWFkeSByZWdpc3RlcmVkIikKICAgICAgKGNs
LWFzc2VydCAoZXEgKHR5cGUtb2YgY2xhc3MpICdndHlwZS1jbGFzcykgbmlsCiAgICAgICAg
ICAgICAgICAgIlR5cGUgaXMgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNsYXNz
KSkpCiAgICAob3IgKGxpc3RwIHBhcmVudHMpIChzZXRxIHBhcmVudHMgKGxpc3QgcGFyZW50
cykpKQogICAgKGNsLWFzc2VydCAobnVsbCAobWVtcSBuYW1lIHBhcmVudHMpKSBuaWwKICAg
ICAgICAgICAgICAgIlR5cGUgaXMgaW4gcGFyZW50czogJVMiIHBhcmVudHMpCiAgICA7OyBT
ZXR1cCBhIHR5cGUgZGVzY3JpcHRvciBmb3IgTkFNRSwgd2l0aCBQQVJFTlRTIGFuZCB0aGUg
ZG9jc3RyaW5nCiAgICA7OyBwb3NzaWJseSBwcmVzZW50IGluIEFSR1MuCiAgICAobGV0ICgo
ZG9jc3RyaW5nIChjYWFyIChtYWNyb2V4cC1wYXJzZS1ib2R5IChjZHIgYXJncykpKSkpCiAg
ICAgIChvciAoc3RyaW5ncCBkb2NzdHJpbmcpIChzZXRxIGRvY3N0cmluZyBuaWwpKQogICAg
ICAoc2V0ZiAoY2wtLWZpbmQtY2xhc3MgbmFtZSkKICAgICAgICAgICAgKGd0eXBlLS1jbGFz
cy1tYWtlIG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKSkKICAgIChpZiBjbGFzcwogICAgICAg
IDs7IENsZWFyIHRoZSBjYWNoZWQgdmFsdWUgb2YgcGFyZW50cyBmb3IgZWFjaCBjaGlsZHJl
biBvZiBhCiAgICAgICAgOzsgbW9kaWZpZWQgZ3R5cGUuCiAgICAgICAgKGRvbGlzdCAoYyAo
Z3R5cGUtY2hpbGRyZW4gbmFtZSkpCiAgICAgICAgICAoY2wtcmVtcHJvcCBjICdndHlwZS0t
YWxscGFyZW50cykpCiAgICAgIDs7IFJlY29yZCB0aGUgbmV3IHR5cGUuCiAgICAgIChwdXNo
IG5hbWUgZ3R5cGUtLWxpc3QpCiAgICAgIDs7IEFuZCBpdHMgc2VxdWVuY2UgbnVtYmVyLgog
ICAgICAocHV0IG5hbWUgJ2d0eXBlLS1zZXFuIChwcm9nMSBndHlwZS0tc2VxbiAoaW5jZiBn
dHlwZS0tc2VxbikpKSkKICAgIDs7IFRvIGZpbmQgdGhlIG1vc3QgcG9zc2libGUgc3BlY2lm
aWMgZ3R5cGUgb2YgYW4gb2JqZWN0LCBtb3N0CiAgICA7OyBzcGVjaWZpYyB0eXBlcyBtdXN0
IGJlIHRyaWVkIGJlZm9yZSBtb3JlIGdlbmVyYWwgdHlwZXMuCiAgICA7OyBDb21wdXRlIHRo
ZSBndHlwZSBwcmVjZWRlbmNlIGxpc3QgYnkgYSB0b3BvbG9naWMgc29ydCBvZiB0aGUKICAg
IDs7IGd0eXBlcyBkZXBlbmRlbmNpZXMgREFHLiAgQXMgdGhlIERBRyBtYXkgaW5jbHVkZSBu
b24tZ3R5cGVzCiAgICA7OyBuZWVkZWQgdG8gY29ycmVjdGx5IGNvbXB1dGUgdGhlIHByZWNl
ZGVuY2UgbGlzdCwgcmVtb3ZlIHRoZW0KICAgIDs7IGZyb20gdGhlIGZpbmFsIHByZWNlZGVu
Y2UgbGlzdDogYGd0eXBlLW9mJyBkb2Vzbid0IGNoZWNrCiAgICA7OyBub24tZ3R5cGUgYXQg
cnVuIHRpbWUsIGhhbmRsZWQgYnkgdGhlICJ0eXBlLW9mIiBnZW5lcmFsaXplci4KICAgIChz
ZXRxIGd0eXBlLS1saXN0IChzZXEtZmlsdGVyICMnZ3R5cGUtcAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKGd0eXBlLS10b3BvbG9naWMtc29ydAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChndHlwZS0tZGFnKQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICMnZ3R5cGUtLXRpZS1icmVha2VyKSkpCiAgICBuYW1lKSkKCihk
ZWZ1biBndHlwZS0tdW5yZWdpc3RlciAobmFtZSkKICAiVW5yZWdpc3RlciB0aGUgZ3R5cGUg
d2l0aCBOQU1FLiIKICAoY2wtYXNzZXJ0IChudWxsIChndHlwZS1jaGlsZHJlbiBuYW1lKSkg
dCAiVHlwZSBoYXMgY2hpbGRyZW46ICVTIikKICAoY2wtcmVtcHJvcCBuYW1lICdndHlwZS0t
YWxscGFyZW50cykKICAoY2wtcmVtcHJvcCBuYW1lICdndHlwZS0tc2VxbikKICAoY2wtcmVt
cHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXByb3AgbmFtZSAnY2wtZGVmdHlwZS1o
YW5kbGVyKQogIChzZXRxIGd0eXBlLS1saXN0IChkZWxxIG5hbWUgZ3R5cGUtLWxpc3QpKQog
IG5pbCkKCjs7OyMjI2F1dG9sb2FkCihkZWZtYWNybyBkZWZndHlwZSAobmFtZSAmb3B0aW9u
YWwgcGFyZW50cyAmcmVzdCBhcmdzKQogICJEZWZpbmUgTkFNRSBhcyBhIGd0eXBlIHRoYXQg
aW5oZXJpdHMgZnJvbSBQQVJFTlRTLgpJZiBhIGd0eXBlIHdpdGggTkFNRSBhbHJlYWR5IGV4
aXN0cywgcmVwbGFjZSBpdC4KCk5BTUUgaXMgYW4gdW5xdW90ZWQgc3ltYm9sIHJlcHJlc2Vu
dGluZyBhIGd0eXBlLgoKT3B0aW9uYWwgYXJndW1lbnQgUEFSRU5UUyBpcyBlaXRoZXIgYW4g
dW5xdW90ZWQgc3ltYm9sIG9yIGxpc3Qgb2YKc3ltYm9scyBvdGhlciB0aGFuIE5BTUUgcmVw
cmVzZW50aW5nIHR5cGVzIHBhcmVudHMgb2YgTkFNRS4KUEFSRU5UUyBuaWwgb3Igb21pdHRl
ZCBtZWFucyB0aGF0IE5BTUUgaXMgYSByb290IHR5cGUuCgpBbHNvIHBhc3MgTkFNRSBhbmQg
QVJHUyB0byBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIE5BTUUgYXMgYSBuZXcgZGF0YQp0eXBl
LiIKICAoZGVjbGFyZSAoZGVidWcgY2wtZGVmbWFjcm8pIChkb2Mtc3RyaW5nIDQpIChpbmRl
bnQgMykpCiAgKGNsLXdpdGgtZ2Vuc3ltcyAoZXJyKQogICAgYChjb25kaXRpb24tY2FzZSAs
ZXJyCiAgICAgICAgIChwcm9nbgogICAgICAgICAgIChjbC1kZWZ0eXBlICxuYW1lICxAYXJn
cykKICAgICAgICAgICAoZ3R5cGUtLXJlZ2lzdGVyICcsbmFtZSAnLHBhcmVudHMgJyxhcmdz
KSkKICAgICAgIChlcnJvcgogICAgICAgIChndHlwZS0tdW5yZWdpc3RlciAnLG5hbWUpCiAg
ICAgICAgKGVycm9yIChlcnJvci1tZXNzYWdlLXN0cmluZyAsZXJyKSkpKSkpCgooZGVmbWFj
cm8gcmVtZ3R5cGUgKG5hbWUpCiAgIlJlbW92ZSB0aGUgZ3R5cGUgd2l0aCBOQU1FLgpOQU1F
IGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBndHlwZS4KU2lnbmFsIGFu
IGVycm9yIGlmIG90aGVyIGd0eXBlcyBpbmhlcml0IGZyb20gTkFNRS4iCiAgYChwcm9nbgog
ICAgIChjbC1jaGVjay10eXBlICcsbmFtZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogICAgIChn
dHlwZS0tdW5yZWdpc3RlciAnLG5hbWUpKSkKCjs7IEludGVybmFsIGRhdGEgdXNlZCB0byBk
ZXRlY3QgZW5kbGVzcyByZWN1cnNpb24gaW4gJ2d0eXBlLW9mJy4KKGRlZnZhciBndHlwZS0t
b2JqZWN0IChtYWtlLXN5bWJvbCAidm9pZCIpKQooZGVmdmFyIGd0eXBlLS10eXBlIG5pbCkK
CihkZWZ1biBndHlwZS1vZiAob2JqZWN0KQogICJSZXR1cm4gdGhlIG1vc3Qgc3BlY2lmaWMg
cG9zc2libGUgZ3R5cGUgb2YgT0JKRUNULCBvciBuaWwgaWYgbm9uZS4iCiAgOzsgSWdub3Jl
IHJlY3Vyc2l2ZSBjYWxsIG9uIHRoZSBzYW1lIE9CSkVDVCwgd2hpY2ggY2FuIGxlZ2l0aW1h
dGVseQogIDs7IG9jY3VyIHdoZW4sIGZvciBleGFtcGxlLCBhIHBhcmVudCB0eXBlIGlzIGlu
dmVzdGlnYXRpbmcgd2hldGhlcgogIDs7IGFuIG9iamVjdCdzIHR5cGUgaXMgdGhhdCBvZiBv
bmUgb2YgaXRzIGNoaWxkcmVuLgogICh1bmxlc3MgKGVxIG9iamVjdCBndHlwZS0tb2JqZWN0
KQogICAgKGxldCAoKGd0eXBlLS1vYmplY3Qgb2JqZWN0KQogICAgICAgICAgKHR5cGVzIGd0
eXBlLS1saXN0KQogICAgICAgICAgZm91bmQpCiAgICAgIDs7IFRyeSBlYWNoIGd0eXBlLCBm
cm9tIG1vc3Qgc3BlY2lmaWMgdG8gbGVhc3Qgc3BlY2lmaWMsIHVudGlsCiAgICAgIDs7IG9u
ZSBpcyBmb3VuZCBhcyB0aGUgbW9zdCBzcGVjaWZpYyBwb3NzaWJsZSBndHlwZSBvZiBPQkpF
Q1QuCiAgICAgICh3aGlsZSAoYW5kIChub3QgZm91bmQpIHR5cGVzKQogICAgICAgIChsZXQg
KChndHlwZS0tdHlwZSAoY2FyIHR5cGVzKSkpCiAgICAgICAgICAoaWYgKGNsLXR5cGVwIG9i
amVjdCBndHlwZS0tdHlwZSkKICAgICAgICAgICAgICAoc2V0cSBmb3VuZCBndHlwZS0tdHlw
ZSkKICAgICAgICAgICAgKHNldHEgdHlwZXMgKGNkciB0eXBlcykpKSkpCiAgICAgIGZvdW5k
KSkpCgo7OzsgTWV0aG9kIGRpc3BhdGNoaW5nCjs7CihkZWZ1biBndHlwZS0tc3BlY2lhbGl6
ZXJzICh0YWcgJnJlc3QgXykKICAiSWYgVEFHIGlzIGEgZ3R5cGUsIHJldHVybiBpdHMgc3Bl
Y2lhbGl6ZXJzLiIKICAoaWYgKGd0eXBlLXAgdGFnKSAoZ3R5cGUtLWFsbHBhcmVudHMgdGFn
KSkpCgooY2wtZ2VuZXJpYy1kZWZpbmUtZ2VuZXJhbGl6ZXIgZ3R5cGUtLWdlbmVyYWxpemVy
CiAgMTAKICAobGFtYmRhIChvYmogJnJlc3QgXykgYChndHlwZS1vZiAsb2JqKSkKICAjJ2d0
eXBlLS1zcGVjaWFsaXplcnMpCgooY2wtZGVmbWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6
ZXJzIDpleHRyYSAiZ3R5cGUtb2YiICh0eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBv
biBndHlwZXMuIgogIChpZiAoZ3R5cGUtcCB0eXBlKQogICAgICAobGlzdCBndHlwZS0tZ2Vu
ZXJhbGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoKKHByb3ZpZGUgJ2d0eXBl
KQoKOzs7IGd0eXBlLmVsIGVuZHMgaGVyZQo=
--------------K7ayjXP8dGQosZr0arxKGOQ6--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 13 Apr 2025 15:54:02 +0000
Resent-Message-ID: <handler.77725.B77725.174455963913919 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174455963913919
(code B ref 77725); Sun, 13 Apr 2025 15:54:02 +0000
Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 15:53:59 +0000
Received: from localhost ([127.0.0.1]:43508 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3zeh-0003cO-85
for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 11:53:59 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47123)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u3zed-0003c2-TM
for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 11:53:57 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E772B10006B;
Sun, 13 Apr 2025 11:53:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744559622;
bh=YnfLEHgg4HqepaDf4ytmvLQFstc5Y2L9H/2wnqWuIYg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=II37cUntVP3reGSxAIP8eATYSo0juOsVyxKsUy5GiICI4toB1PxS6kqu4kk7BoXBB
Fo+gFclTqoDQyugKepX4BMPReanOan7ZgJIbew/ZbG/d66sB9dm1/l/ty616OcKAM7
iQNCMhRtOBJ70iyXDwMbxzKEsAIBKplCDrdFxrezxvsw3NVAGWPHCJbf/z7JQ4OXtQ
3ykegZcx5gGLz4XZ3wNIl8v1iGq07dsN6YpnLDNcar+gnAcJnBbsjfA0+U0MkmZZ7Q
30zzANj1CCHXRV07HPB0FzLaDEbFsMmU6v7ci6ZNJEArbP5l23dtlI2G+URKYu4VnK
ExTXURwEAzlYA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B522E100029;
Sun, 13 Apr 2025 11:53:42 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74867120755;
Sun, 13 Apr 2025 11:53:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
Message-ID: <jwvbjt08401.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
Date: Sun, 13 Apr 2025 11:53:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.386 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> For instance, if you define an icon type like this:
>
> (defgtype icon nil ()
> "Builtin icon type."
> '(and symbol (satisfies iconp)))
>
> (gtype-of 'button)
> =3D> icon
> (cl-type-of 'button)
> =3D> symbol
>
> So you cannot have two methods with the same name, one to handle the
> symbol type, and one to handle the icon type. I agree, it is a
> limitation. Is this your point?
Kind of. Note: you can. It's just that with your current code I expect
it will misbehave (rather than signal an error).
BTW, for the above case, your code could recognize that `icon` is
a subtype of `symbol` and tell that to cl-generic.
> I wonder if in practice it is really inconvenient, and worth the
> trouble of complicate more the implementation?
I don't think I understand what compilations you're talking about, nor
what kind of inconvenience you're referring to.
> Isn't it clearer to use different methods for icons and symbols?
> Aren't these types fundamentally different, and isn't the fact that an
> icon is a symbol just an implementation choice?
The question is not whether it's desirable, but whether we can provide
an implementation that works without too many quirks. =F0=9F=99=82
>> BTW if you do
>> (defgtype cons-car-foo nil ()
>> "A cons with a `foo' car."
>> `(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
>> (defgtype cons-cdr-foo nil ()
>> "A cons with a `foo' cdr."
>> `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
>> what's the `(gtype-of '(foo . foo))` ?
>
> Regarding this point, perhaps it would be possible to use an heuristic
> like: "in case of conflict, the last defined type is chosen as the
> most specific"?
I'm pretty sure some of your users will still be confused when their
methods are not used, just because some other part of their `cons` cells
happens to have a value recognized by an unrelated type.
And of course, they'd probably also be confused if the method that
handles `cons` is not used for those cons-cells.
>> Yeah, it's unsatisfactorily intricate, indeed. It's designed first and
>> foremost to keep the dispatch "simple and reasonable fast", at the cost
>> of making `cl-generic-define-generalizer` a very sharp tool. =F0=9F=99=
=82
>> I have recently been thinking about how to make it more reliable (which
>> would also make it more flexible/powerful, allowing the definition of
>> both `and` and `or` specializers). I have some vague idea, but there's
>> no code at all yet, and it might come with some non-trivial tradeoffs
>> (e.g. preloading the byte-compiler).
> I can't wait to see this :-)
I know I wrote "yet", but I have a very long list of "ideas I've had":
most of those will never become concrete.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 13 Apr 2025 16:29:01 +0000
Resent-Message-ID: <handler.77725.B77725.174456173720589 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174456173720589
(code B ref 77725); Sun, 13 Apr 2025 16:29:01 +0000
Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 16:28:57 +0000
Received: from localhost ([127.0.0.1]:43577 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u40CW-0005Ly-RL
for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 12:28:57 -0400
Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:50109
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u40CS-0005Lk-Bs
for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 12:28:54 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 40CKu1K2mNyiG40COuEQKp; Sun, 13 Apr 2025 18:28:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744561730;
bh=EEuEGaz0rOBE8XITCKzgxRq/cR6SLVqlrjOsgICsbnk=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=ofXnfJoRf3FQ03nNxKJqVKE55DFwjeKVmzf7zbV3eftiiXZBovIhJTePZriE1AM5H
zrIomncj2JFCJJ2fjLmOK5S1YEdkJ7fSjE1A6s3vwZ3Y6Di80ELhi5V2QVHD+DMzGi
GsnnRc/ccXDiZKMbCM2QOBHG6WRlFbeBMB2FQUYFKnaO+9wbyuiUCfXFIXFafGrCwT
ztdiF3lrco6TuKtWSzTfYbtdMJCfRqUyUpIdNcy7TNANBOG4EnoS1lAkcZqrHIfwLh
HTKay/oWTmbrILD3bmsUJTryNtyvBAV4Yi8HaASrBZAyMQQHqRFYT69/aJDvtYUgPr
C4A0S/0ABsMyw==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sun, 13 Apr 2025 18:28:50 +0200
X-ME-IP: 90.112.40.65
Message-ID: <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
Date: Sun, 13 Apr 2025 18:28:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvbjt08401.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-13 17:53, Stefan Monnier wrote:
>> For instance, if you define an icon type like this:
>>
>> (defgtype icon nil ()
>> "Builtin icon type."
>> '(and symbol (satisfies iconp)))
>>
>> (gtype-of 'button)
>> => icon
>> (cl-type-of 'button)
>> => symbol
>>
>> So you cannot have two methods with the same name, one to handle the
>> symbol type, and one to handle the icon type. I agree, it is a
>> limitation. Is this your point?
>
> Kind of. Note: you can. It's just that with your current code I expect
> it will misbehave (rather than signal an error).
>
> BTW, for the above case, your code could recognize that `icon` is
> a subtype of `symbol` and tell that to cl-generic.
>
>> I wonder if in practice it is really inconvenient, and worth the
>> trouble of complicate more the implementation?
>
> I don't think I understand what compilations you're talking about, nor
> what kind of inconvenience you're referring to.
>
>> Isn't it clearer to use different methods for icons and symbols?
>> Aren't these types fundamentally different, and isn't the fact that an
>> icon is a symbol just an implementation choice?
>
> The question is not whether it's desirable, but whether we can provide
> an implementation that works without too many quirks. 🙂
>
>>> BTW if you do
>>> (defgtype cons-car-foo nil ()
>>> "A cons with a `foo' car."
>>> `(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
>>> (defgtype cons-cdr-foo nil ()
>>> "A cons with a `foo' cdr."
>>> `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
>>> what's the `(gtype-of '(foo . foo))` ?
>>
>> Regarding this point, perhaps it would be possible to use an heuristic
>> like: "in case of conflict, the last defined type is chosen as the
>> most specific"?
>
> I'm pretty sure some of your users will still be confused when their
> methods are not used, just because some other part of their `cons` cells
> happens to have a value recognized by an unrelated type.
>
> And of course, they'd probably also be confused if the method that
> handles `cons` is not used for those cons-cells.
>
>>> Yeah, it's unsatisfactorily intricate, indeed. It's designed first and
>>> foremost to keep the dispatch "simple and reasonable fast", at the cost
>>> of making `cl-generic-define-generalizer` a very sharp tool. 🙂
>>> I have recently been thinking about how to make it more reliable (which
>>> would also make it more flexible/powerful, allowing the definition of
>>> both `and` and `or` specializers). I have some vague idea, but there's
>>> no code at all yet, and it might come with some non-trivial tradeoffs
>>> (e.g. preloading the byte-compiler).
>> I can't wait to see this :-)
>
> I know I wrote "yet", but I have a very long list of "ideas I've had":
> most of those will never become concrete.
>
>
> Stefan
>
Hi Stefan
Thank you again for your very valuable input.
I am afraid, this discussion just confirms that I don't understand well
enough how cl-generic works, and how it can be improved the correct way :-(
Have a nice Sunday.
David
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 13 Apr 2025 17:11:02 +0000
Resent-Message-ID: <handler.77725.B77725.174456424929035 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174456424929035
(code B ref 77725); Sun, 13 Apr 2025 17:11:02 +0000
Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 17:10:49 +0000
Received: from localhost ([127.0.0.1]:43679 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u40r2-0007YF-RW
for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 13:10:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46662)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u40r0-0007Xv-6F
for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 13:10:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1A51D10006B;
Sun, 13 Apr 2025 13:10:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744564239;
bh=aSSofOLOc4E1pgkVpmkiD8zSUSZdSkVVYtiRn8TEpQM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=bbI/7bNiMQto7q4mC/Tcz3UjDB8nhzdCzhJvGLDws9C70D1F+R0TnqWJ+AKcEgjoo
es98qd5Zb1lXk2jeJh7dmsO0Bu8B+9jUAGHgAwy7K6zKYHLkbJMjdP8ICtfx4M41Bx
R37wiQYhprFOpID811gCDTyXwSId4JKpPlo+GAepKWyt4IwYQsMRgES26U0UEfniNm
emnFa8DBrvVJwkGXp8EN4qxrm0aKl/qxiYDMhEoXaNRb2D0NhnhsP1fEnywMexlSrC
JGN3YDUxFmibhzzHk9/o9u587SJDSuNHhQTWlrr9NC9OQhqdxzfzbIbPe3IFMkNkHr
A62GOn9gktaBA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 23B88100029;
Sun, 13 Apr 2025 13:10:39 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA45512075A;
Sun, 13 Apr 2025 13:10:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
Message-ID: <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
Date: Sun, 13 Apr 2025 13:10:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.385 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Thank you again for your very valuable input.
> I am afraid, this discussion just confirms that I don't understand well
> enough how cl-generic works, and how it can be improved the correct way :-(
In case it can help, here's some example:
(cl-defmethod my-foo ((x symbol))
(message "%S is a symbol" x))
If I call `(my-foo nil)` it will report that nil is a symbol, even
though `(cl-type-of nil)` returns `null` rather than `symbol`.
If I add a new method for `null`:
(cl-defmethod my-foo ((x null))
(message "%S is null" x)
(cl-call-next-method))
Now a call to `(my-foo nil)` will report both that nil is null and that
it's a symbol (in that order).
For your `button` example, we'd similarly want that
(cl-defmethod my-foo ((x icon))
(message "%S is an icon" x)
(cl-call-next-method))
`(my-foo 'button)` reports button as both an icon and a symbol (in that
order). Now let's say we add:
(defgtype face nil ()
"Builtin face type."
'(and symbol (satisfies facep)))
(cl-defmethod my-foo ((x face))
(message "%S is an face" x)
(cl-call-next-method))
We'd want `(my-foo 'button)` now to report that button is an icon,
a face, and a symbol (and here I think it's OK if the ordering between
icon and face is arbitrary, tho they should both come before symbol).
One way you could do that is for your `(gtype-of 'button)` to return
some new `face&icon` type and to have your SPECIALIZERS-FUNCTION return
the list `(face icon symbol)` or `(icon face symbol)` for that type.
Does that help?
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Apr 2025 14:25:02 +0000
Resent-Message-ID: <handler.77725.B77725.174464065828986 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174464065828986
(code B ref 77725); Mon, 14 Apr 2025 14:25:02 +0000
Received: (at 77725) by debbugs.gnu.org; 14 Apr 2025 14:24:18 +0000
Received: from localhost ([127.0.0.1]:48422 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4KjR-0007XP-3K
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 10:24:18 -0400
Received: from smtp-17.smtpout.orange.fr ([80.12.242.17]:35409
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u4KjM-0007XC-Mt
for 77725 <at> debbugs.gnu.org; Mon, 14 Apr 2025 10:24:15 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 4KjEueiXbETiN4KjIul78K; Mon, 14 Apr 2025 16:24:10 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744640650;
bh=mLP7FKcYRctCE9hMv+eccfNJDiiZUjEJ/MlqbcFAEGg=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=OK+P8KhKq8J+ul9wLZ3xzDlsJkiQvw9io0E4C5o1E+P4FVaHKIoe64fgPBhk1HeYx
xRAbcjXLwYO3stf6uIDoNMoFr9TGosXIaW67yUyLcZjPabQ3OTcmdxFfw2xE15upNP
eE2ooRc0t8D4XTiCgGandTO05B/W7aAX8hAbo8N+17Aw7GGrAR2pHwd60tgcBpGO9R
8ISnBQuR2J2PSejomsdijJhG2zHKfvsOUsMwhQwUO91V+wCBNrkspBc0eXpF6OXCjH
DQ/8/uya/06vUYUx3I4oD+gzyQS9XPaI85uABgHiPy4lgg8jz5zCfszSdAruYVcBcx
AesVosgYBUM6Q==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Mon, 14 Apr 2025 16:24:10 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------NqVnDj0IabAnTmcUIWM0h849"
Message-ID: <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
Date: Mon, 14 Apr 2025 16:24:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------NqVnDj0IabAnTmcUIWM0h849
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2025-04-13 19:10, Stefan Monnier wrote:
>
> In case it can help, here's some example:
>
> (cl-defmethod my-foo ((x symbol))
> (message "%S is a symbol" x))
>
> If I call `(my-foo nil)` it will report that nil is a symbol, even
> though `(cl-type-of nil)` returns `null` rather than `symbol`.
>
> If I add a new method for `null`:
>
> (cl-defmethod my-foo ((x null))
> (message "%S is null" x)
> (cl-call-next-method))
>
> Now a call to `(my-foo nil)` will report both that nil is null and that
> it's a symbol (in that order).
>
> For your `button` example, we'd similarly want that
>
> (cl-defmethod my-foo ((x icon))
> (message "%S is an icon" x)
> (cl-call-next-method))
>
> `(my-foo 'button)` reports button as both an icon and a symbol (in that
> order). Now let's say we add:
>
> (defgtype face nil ()
> "Builtin face type."
> '(and symbol (satisfies facep)))
>
> (cl-defmethod my-foo ((x face))
> (message "%S is an face" x)
> (cl-call-next-method))
>
> We'd want `(my-foo 'button)` now to report that button is an icon,
> a face, and a symbol (and here I think it's OK if the ordering between
> icon and face is arbitrary, tho they should both come before symbol).
>
> One way you could do that is for your `(gtype-of 'button)` to return
> some new `face&icon` type and to have your SPECIALIZERS-FUNCTION return
> the list `(face icon symbol)` or `(icon face symbol)` for that type.
>
> Does that help?
Thank you very much Stefan, it helped much!
J'aperçois enfin la lumière au bout du tunnel :-)
I understand more how cl-generic works, and I reworked gtype.el
(attached) according to your inputs and my better understanding.
Now your examples above give the expected results :-)
And:
(gtype-of '(foo . foo))
=> (cons-car-foo cons-cdr-foo cons)
(gtype--specializers (gtype-of '(foo . foo)))
=> (cons-car-foo cons-cdr-foo cons list sequence t)
--------------NqVnDj0IabAnTmcUIWM0h849
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el"
Content-Disposition: attachment; filename="gtype.el"
Content-Transfer-Encoding: base64
Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g
bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u
Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50
YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw
cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg
cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl
ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m
IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg
UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs
b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv
bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k
cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg
ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg
dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KOzsK
OzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1h
Y3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rp
b24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9mIGFuIG9iamVjdC4KOzsKOzsgLSBgcmVtZ3R5
cGUnLCBhIG1hY3JvIHRoYXQgcmVtb3ZlcyBhIGd0eXBlLgo7Owo7OyBBIHRyaXZpYWwgZXhh
bXBsZToKOzsKOzsgKGRlZmd0eXBlIG5lZ2F0aXZlIG5pbCAoKQo7OyAgICJBIG5lZ2F0aXZl
IG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlzZmllcyBtaW51c3ApKSkKOzsKOzsg
KGRlZmd0eXBlIHplcm8gbmlsICgpCjs7ICAgIkEgemVybyBudW1iZXIiCjs7ICAgJyhhbmQg
bnVtYmVyIChzYXRpc2ZpZXMgemVyb3ApKSkKOzsKOzsgKGRlZmd0eXBlIHBvc2l0aXZlIG5p
bCAoKQo7OyAgICJBIHBvc2l0aXZlIG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlz
ZmllcyBwbHVzcCkpKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBuZWdh
dGl2ZSkpCjs7ICAgKGZvcm1hdCAibmVnYXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7IChj
bC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHplcm8pKQo7OyAgIChmb3JtYXQgInplcm8g
bnVtYmVyLCAlcyIgbikpCjs7Cjs7IChjbC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHBv
c2l0aXZlKSkKOzsgICAoZm9ybWF0ICJwb3NpdGl2ZSBudW1iZXIsICVzIiBuKSkKOzsKOzsg
KHRlc3QtbnVtYmVyIC0xMjMuMCkKOzsgPT4gIm5lZ2F0aXZlIG51bWJlciwgLTEyMy4wIgo7
OyAodGVzdC1udW1iZXIgKGFicyAtMTIzLjApKQo7OyA9PiAicG9zaXRpdmUgbnVtYmVyLCAx
MjMuMCIKOzsgKHRlc3QtbnVtYmVyIChyb3VuZCAwLjAwMDAwMDAwMDAwMSkpCjs7ID0+ICJ6
ZXJvIG51bWJlciwgMCIKOzsKOzsgUGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnM6Cjs7Cjs7
IFRoZSBjcml0aWNhbCBwb2ludCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpcyB0
aGUgZnVuY3Rpb24KOzsgYGd0eXBlLW9mJyB3aGljaCBzZXF1ZW50aWFsbHkgdHJpZXMgYWxs
IGtub3duIGd0eXBlcyB0byBjb2xsZWN0IGFsbAo7OyB0aG9zZSBhbiBvYmplY3QgYmVsb25n
cyB0bywgZnJvbSB0aGUgbW9zdCBzcGVjaWZpYyB0byB0aGUgbW9zdAo7OyBnZW5lcmFsIHR5
cGUuICBUaGVyZWZvcmUsIHRoZSBtYXhpbXVtIHRpbWUgdG8gZmluZCBhbiBvYmplY3QncyB0
eXBlCjs7IGRpcmVjdGx5IGRlcGVuZHMgb24gdGhlIG51bWJlciBvZiBndHlwZXMuICBJcyB0
aGVyZSBhIGJldHRlcgo7OyBzb2x1dGlvbj8gIEFueXdheSwgYXNzdW1pbmcgdGhhdCBlYWNo
IHNpbmdsZSB0ZXN0IHRvIGtub3cgd2hldGhlcgo7OyBhbiBvYmplY3QgaXMgb2YgYSBnaXZl
biBndHlwZSBpcyByZWFzb25hYmx5IGZhc3QsIHRoZSBwZXJmb3JtYW5jZQo7OyBvZiB0aGlz
IGltcGxlbWVudGF0aW9uIHNlZW1zIGFjY2VwdGFibGUgKGJhc2VkIG9uIHRoZSB0cml2aWFs
Cjs7IGV4YW1wbGUgYWJvdmUsIGF0dGVtcHRpbmcgMSwwMDAgZ3R5cGUgY2hlY2tzIHRha2Vz
IGFib3V0IGhhbGYgYQo7OyBtaWxsaXNlY29uZCBvbiBteSBzZXR1cCkuCjs7Cgo7OzsgQ29k
ZToKOzsKKHJlcXVpcmUgJ2NsLWxpYikKKGV2YWwtd2hlbi1jb21waWxlIChyZXF1aXJlICdj
bC1tYWNzKSkgIDtGb3IgY2wtLWZpbmQtY2xhc3MuCgooZGVmdmFyIGd0eXBlLS1saXN0IG5p
bAogICJQcmVjZWRlbmNlIGxpc3Qgb2YgdGhlIGRlZmluZWQgZ3R5cGVzLiIpCihkZWZ2YXIg
Z3R5cGUtLXNlcW4gMAogICJTZXF1ZW5jZSBudW1iZXIgb2YgZGVmaW5lZCBndHlwZXMuIikK
CihkZWZpbmUtaW5saW5lIGd0eXBlLXAgKG9iamVjdCkKICAiUmV0dXJuIG5vbi1uaWwgaWYg
dGhlIHR5cGUgb2YgT0JKRUNUIGlzIGEgZ3R5cGUuIgogIChpbmxpbmUtbGV0ZXZhbHMgKG9i
amVjdCkKICAgIChpbmxpbmUtcXVvdGUKICAgICAoYW5kIChzeW1ib2xwICxvYmplY3QpCiAg
ICAgICAgICAoZXEgKHR5cGUtb2YgKGNsLS1maW5kLWNsYXNzICxvYmplY3QpKSAnZ3R5cGUt
Y2xhc3MpKSkpKQoKKGNsLWRlZnN0cnVjdAogICAgKGd0eXBlLWNsYXNzCiAgICAgKDppbmNs
dWRlIGNsLS1jbGFzcykKICAgICAoOm5vaW5saW5lIHQpCiAgICAgKDpjb25zdHJ1Y3RvciBu
aWwpCiAgICAgKDpjb25zdHJ1Y3RvciBndHlwZS0tY2xhc3MtbWFrZQogICAgICAgICAgICAg
ICAgICAgKG5hbWUKICAgICAgICAgICAgICAgICAgICBkb2NzdHJpbmcKICAgICAgICAgICAg
ICAgICAgICBwYXJlbnQtdHlwZXMKICAgICAgICAgICAgICAgICAgICAmYXV4IChwYXJlbnRz
CiAgICAgICAgICAgICAgICAgICAgICAgICAgKG1hcGNhcgogICAgICAgICAgICAgICAgICAg
ICAgICAgICAobGFtYmRhICh0eXBlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChv
ciAoY2wtLWZpbmQtY2xhc3MgdHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGVycm9yICJVbmtub3duIHR5cGU6ICVTIiB0eXBlKSkpCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHBhcmVudC10eXBlcykpKSkKICAgICAoOmNvcGllciBuaWwpKQogICJUeXBl
IGRlc2NyaXB0b3JzIGZvciBndHlwZXMuIikKCihkZWZpbmUtaW5saW5lIGd0eXBlLXBhcmVu
dHMgKG5hbWUpCiAgIkdldCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEg
c3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxp
c3Qgb2YgdHlwZXMuIgogIChpbmxpbmUtcXVvdGUKICAgKGNsLS1jbGFzcy1hbGxwYXJlbnRz
IChjbC0tZmluZC1jbGFzcyAsbmFtZSkpKSkKCihkZWZ1biBndHlwZS1jaGlsZHJlbiAobmFt
ZSkKICAiR2V0IGNoaWxkcmVuIG9mIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBz
eW1ib2wgcmVwcmVzZW50aW5nIGEgZ3R5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxp
c3Qgb2YgdHlwZXMuIgogIChjbC1jaGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBndHlwZS1w
KSkKICAobGV0IChjaGlsZHJlbikKICAgIChkb2xpc3QgKGVsdCBndHlwZS0tbGlzdCkKICAg
ICAgKG9yIChlcSBuYW1lIGVsdCkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIChndHlwZS1w
YXJlbnRzIGVsdCkpCiAgICAgICAgICAgICAgKHB1c2ggZWx0IGNoaWxkcmVuKSkpKQogICAg
Y2hpbGRyZW4pKQoKKGRlZnVuIGd0eXBlLS10aWUtYnJlYWtlciAobTEgbTIpCiAgIlJldHVy
biB0aGUgbGVzcyBzcGVjaWZpYyBvZiB0d28gbWluLWVsZW1lbnRzIE0xIGFuZCBNMi4KVGhh
dCBpcywgdGhlIG1pbi1lbGVtZW50IGZpcnN0IHB1c2hlZCBpbiB0aGUgZ3R5cGUgcHJlY2Vk
ZW5jZSBsaXN0LApvcmRlcmVkIGZyb20gbW9zdCB0byBsZXNzIHNwZWNpZmljIHR5cGVzLgpJ
ZiBNMSBhbmQgTTIgaG9sZCBndHlwZXMsIHByZWZlciB0aGUgb25lIHdpdGggdGhlIGZpcnN0
IGRlZmluZWQgZ3R5cGUuCk90aGVyd2lzZSwgcHJlZmVyIE0xLCB0aGUgZmlyc3QgbWluLWVs
ZW1lbnQgZm91bmQgaW4gdGhlIERBRy4iCiAgKGlmLWxldCogKChpMSAoZ2V0IChjYXIgbTEp
ICdndHlwZS0tc2VxbikpCiAgICAgICAgICAgIChpMiAoZ2V0IChjYXIgbTIpICdndHlwZS0t
c2VxbikpKQogICAgICAoaWYgKDwgaTEgaTIpIG0xIG0yKQogICAgbTEpKQoKKGRlZnVuIGd0
eXBlLS10b3BvbG9naWMtc29ydCAoZ3JhcGggJm9wdGlvbmFsIHRpZS1icmVha2VyKQogICJS
ZXR1cm4gdGhlIHRvcG9sb2dpY2FsbHkgc29ydGVkIGVsZW1lbnRzIG9mIEdSQVBILgpHUkFQ
SCBtdXN0IGJlIGEgdmFsaWQgZGlyZWN0ZWQgYWN5Y2xpYyBncmFwaCAoREFHKSBhcyBhIGxp
c3Qgb2YKZWxlbWVudHMgKFZpIFtWaiBWay4uLlZuXSkgd2hpY2ggbWVhbnMgdGhhdCBWaSBk
ZXBlbmRzIHVwb24gVmosIFZqCnVwb24gVmssIGV0Yy4sIG9yIGRlcGVuZHMgdXBvbiBub3Ro
aW5nLiAgU2lnbmFsIGFuIGVycm9yIG90aGVyd2lzZS4KRWxlbWVudHMgYXJlIGNvbXBhcmVk
IHVzaW5nIGBlcScuCgpJZiBub24tbmlsLCBUSUUtQlJFQUtFUiBtdXN0IGJlIGEgZnVuY3Rp
b24gdGhhdCByZWNlaXZlcyB0aGUKcHJldmlvdXNseSBhbmQgbGFzdCBmb3VuZCBtaW4tZWxl
bWVudHMoKiksIGFuZCBtdXN0IHJldHVybiBvbmUgb2YKdGhlbS4gIElmIFRJRS1CUkVBS0VS
IGlzIG5pbCBvciBvbWl0dGVkLCBwcmVmZXIgdGhlIGZpcnN0IG1pbi1lbGVtZW50CmZvdW5k
LCBpLmUuIHRoZSBvbmUgdGhhdCBhcHBlYXJzIGZpcnN0IGluIHRoZSBuYXR1cmFsIG9yZGVy
IG9mIHRoZQpEQUcuCgpbKl0gQSBtaW4tZWxlbWVudCBpcyBhbiBlbGVtZW50IHdpdGggbm8g
c3VjY2Vzc29yLCBsaWtlIChEKS4KClNvbWUgZXhhbXBsZXM6CgogIChndHlwZS0tdG9wb2xv
Z2ljLXNvcnQgXFw9JygoQSBCIEMpIChCIEQpIChDIEQpIChEKSkpCiAgPT4gKEEgQiBDIEQp
CgogIChndHlwZS0tdG9wb2xvZ2ljLXNvcnQgXFw9JygoQSBCIEMpIChCIEQpIChDIEQpIChE
KSkKICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKF9wcmV2IGxhc3QpIGxhc3Qp
KQogID0+IChBIEMgQiBEKQoKICAoZ3R5cGUtLXRvcG9sb2dpYy1zb3J0IFxcPScoKEEgQiBD
KSAoQiBEKSAoRCBCKSAoRCkpKQogID0+IGVycm9yIgogIChkZWNsYXJlIChzaWRlLWVmZmVj
dC1mcmVlIHQpKQogIChjbC1sYWJlbHMgKChyZW1xLW1pbmltYWwgKG0gZykKICAgICAgICAg
ICAgICAgIDs7IFJlbW92ZSBtaW4tZWxlbWVudCBNIGZyb20gRy4KICAgICAgICAgICAgICAg
IChsZXQgKChtZSAoY2FyIG0pKSByZXN1bHQpCiAgICAgICAgICAgICAgICAgIChkb2xpc3Qg
KGUgKGRlbHEgbSBnKSkKICAgICAgICAgICAgICAgICAgICAocHVzaCAoY29ucyAoY2FyIGUp
IChyZW1xIG1lIChjZHIgZSkpKSByZXN1bHQpKQogICAgICAgICAgICAgICAgICByZXN1bHQp
KQogICAgICAgICAgICAgIChuZXh0LW1pbmltYWwgKGcpCiAgICAgICAgICAgICAgICA7OyBS
ZXR1cm4gdGhlIG5leHQgbWluLWVsZW1lbnQgZm91bmQgaW4gRy4KICAgICAgICAgICAgICAg
IChsZXQgKG0pCiAgICAgICAgICAgICAgICAgIChkb2xpc3QgKGUgZykKICAgICAgICAgICAg
ICAgICAgICAob3IgKGNkciBlKQogICAgICAgICAgICAgICAgICAgICAgICA7OyBXaGVuIHRo
ZXJlIGFyZSB0d28gbWluLWVsZW1lbnRzLCBjYWxsIHRoZQogICAgICAgICAgICAgICAgICAg
ICAgICA7OyBUSUUtQlJFQUtFUiB0byBkZWNpZGUgd2hpY2ggb25lIGlzIG1vcmUKICAgICAg
ICAgICAgICAgICAgICAgICAgOzsgc3BlY2lmaWMuCiAgICAgICAgICAgICAgICAgICAgICAg
IChzZXRxIG0gKGlmIG0gKGZ1bmNhbGwgdGllLWJyZWFrZXIgbSBlKSBlKSkpKQogICAgICAg
ICAgICAgICAgICBtKSkpCiAgICAob3IgdGllLWJyZWFrZXIgKHNldHEgdGllLWJyZWFrZXIg
KGxhbWJkYSAocHJldiBfbmV4dCkgcHJldikpKQogICAgKGxldCAoKGcgKGNvcHktc2VxdWVu
Y2UgZ3JhcGgpKSB0cykKICAgICAgKHdoaWxlICh3aGVuLWxldCogKChtIChuZXh0LW1pbmlt
YWwgZykpKQogICAgICAgICAgICAgICAoc2V0cSBnIChyZW1xLW1pbmltYWwgbSBnKSkKICAg
ICAgICAgICAgICAgKHB1c2ggKGNhciBtKSB0cykpKQogICAgICAoY2wtYXNzZXJ0IChlcWwg
KGxlbmd0aCBncmFwaCkgKGxlbmd0aCB0cykpIG5pbAogICAgICAgICAgICAgICAgICJJbnZh
bGlkIGdyYXBoLCAlUyIgdHMpCiAgICAgIHRzKSkpCgooZGVmdW4gZ3R5cGUtLWRhZyAoKQog
ICJSZXR1cm4gYSBEQUcgZnJvbSB0aGUgbGlzdCBvZiBkZWZpbmVkIGd0eXBlcy4iCiAgKGNs
LWxhYmVscyAoKGFsbHBhcmVudHMgKGNsYXNzKQogICAgICAgICAgICAgICAgKGxldCAoKHR5
cGUgKGNsLS1jbGFzcy1uYW1lIGNsYXNzKSkpCiAgICAgICAgICAgICAgICAgIDs7IEV4Y2x1
ZGUgbm9uLWd0eXBlcyBmcm9tIHRoZSBEQUcuICBgZ3R5cGUtb2YnCiAgICAgICAgICAgICAg
ICAgIDs7IGRvZXNuJ3QgY2hlY2sgbm9uLWd0eXBlcyBhdCBydW4gdGltZSwgdGhleSBhcmUK
ICAgICAgICAgICAgICAgICAgOzsgaGFuZGxlZCBieSB0aGUgInR5cGUtb2YiIGdlbmVyYWxp
emVyLgogICAgICAgICAgICAgICAgICAoaWYgKGd0eXBlLXAgdHlwZSkKICAgICAgICAgICAg
ICAgICAgICAgIChjb25zIHR5cGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgIChtZXJn
ZS1vcmRlcmVkLWxpc3RzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1hcGNhciAj
J2FsbHBhcmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0t
Y2xhc3MtcGFyZW50cyBjbGFzcykpKSkpKSkpCiAgICAobWFwY2FyIChsYW1iZGEgKGd0eXBl
KSAoYWxscGFyZW50cyAoY2wtLWZpbmQtY2xhc3MgZ3R5cGUpKSkKICAgICAgICAgICAgZ3R5
cGUtLWxpc3QpKSkKCihkZWZ1biBndHlwZS0tcmVnaXN0ZXIgKG5hbWUgJm9wdGlvbmFsIHBh
cmVudHMgYXJncykKICAiUmVnaXN0ZXIgYSBndHlwZSB3aXRoIE5BTUUgYW5kIFBBUkVOVFMu
CkFSR1MgYXJlIHRob3NlIHRoYXQgd2lsbCBiZSBwYXNzZWQgdG8gYGNsLWRlZnR5cGUnLiIK
ICA7OyBBdCB0aGlzIHBvaW50IE5BTUUgbXVzdCBiZSBhIGRlZmluZWQgdHlwZS4KICAoY2wt
YXNzZXJ0IChnZXQgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyKSBuaWwKICAgICAgICAgICAg
ICJVbmtub3duIHR5cGUgJVMiIG5hbWUpCiAgKGxldCAoKGNsYXNzIChjbC0tZmluZC1jbGFz
cyBuYW1lKSkKICAgICAgICAocmVnZWQgKG1lbXEgbmFtZSBndHlwZS0tbGlzdCkpKQogICAg
KGlmIChudWxsIGNsYXNzKQogICAgICAgIChjbC1hc3NlcnQgKG51bGwgcmVnZWQpIG5pbCAi
RXhpc3RpbmcgdHlwZSBub3QgcmVnaXN0ZXJlZCIpCiAgICAgIChjbC1hc3NlcnQgcmVnZWQg
bmlsICJOZXcgdHlwZSBhbHJlYWR5IHJlZ2lzdGVyZWQiKQogICAgICAoY2wtYXNzZXJ0IChl
cSAodHlwZS1vZiBjbGFzcykgJ2d0eXBlLWNsYXNzKSBuaWwKICAgICAgICAgICAgICAgICAi
VHlwZSBpcyBpbiBhbm90aGVyIGNsYXNzOiAlUyIgKHR5cGUtb2YgY2xhc3MpKSkKICAgIChv
ciAobGlzdHAgcGFyZW50cykgKHNldHEgcGFyZW50cyAobGlzdCBwYXJlbnRzKSkpCiAgICAo
Y2wtYXNzZXJ0IChudWxsIChtZW1xIG5hbWUgcGFyZW50cykpIG5pbAogICAgICAgICAgICAg
ICAiVHlwZSBpcyBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykKICAgIDs7IFNldHVwIGEgdHlw
ZSBkZXNjcmlwdG9yIGZvciBOQU1FLCB3aXRoIFBBUkVOVFMgYW5kIHRoZQogICAgOzsgZG9j
c3RyaW5nIHBvc3NpYmx5IHByZXNlbnQgaW4gQVJHUy4KICAgIChsZXQgKChkb2NzdHJpbmcg
KGNhYXIgKG1hY3JvZXhwLXBhcnNlLWJvZHkgKGNkciBhcmdzKSkpKSkKICAgICAgKG9yIChz
dHJpbmdwIGRvY3N0cmluZykgKHNldHEgZG9jc3RyaW5nIG5pbCkpCiAgICAgIChzZXRmIChj
bC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAoZ3R5cGUtLWNsYXNzLW1ha2UgbmFt
ZSBkb2NzdHJpbmcgcGFyZW50cykpKQogICAgKGlmIGNsYXNzCiAgICAgICAgOzsgQ2xlYXIg
Y2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVycyB3aXRoIE5BTUUuCiAgICAgICAgKGd0eXBl
LS1yZXNldC1zcGVjaWFsaXplcnMgbmFtZSkKICAgICAgOzsgUmVjb3JkIHRoZSBuZXcgdHlw
ZS4KICAgICAgKHB1c2ggbmFtZSBndHlwZS0tbGlzdCkKICAgICAgOzsgQW5kIGl0cyBzZXF1
ZW5jZSBudW1iZXIuCiAgICAgIChwdXQgbmFtZSAnZ3R5cGUtLXNlcW4gKHByb2cxIGd0eXBl
LS1zZXFuIChpbmNmIGd0eXBlLS1zZXFuKSkpKQogICAgOzsgVG8gZmluZCB0aGUgbW9zdCBw
b3NzaWJsZSBzcGVjaWZpYyBndHlwZSBvZiBhbiBvYmplY3QsIG1vc3QKICAgIDs7IHNwZWNp
ZmljIHR5cGVzIG11c3QgYmUgdHJpZWQgYmVmb3JlIG1vcmUgZ2VuZXJhbCB0eXBlcy4KICAg
IDs7IENvbXB1dGUgdGhlIGd0eXBlIHByZWNlZGVuY2UgbGlzdCBieSBhIHRvcG9sb2dpYyBz
b3J0IG9mIHRoZQogICAgOzsgZ3R5cGVzIGRlcGVuZGVuY2llcyBEQUcuCiAgICAoc2V0cSBn
dHlwZS0tbGlzdCAoZ3R5cGUtLXRvcG9sb2dpYy1zb3J0CiAgICAgICAgICAgICAgICAgICAg
ICAgKGd0eXBlLS1kYWcpICMnZ3R5cGUtLXRpZS1icmVha2VyKSkKICAgIG5hbWUpKQoKKGRl
ZnVuIGd0eXBlLS11bnJlZ2lzdGVyIChuYW1lKQogICJVbnJlZ2lzdGVyIHRoZSBndHlwZSB3
aXRoIE5BTUUuIgogIChjbC1hc3NlcnQgKG51bGwgKGd0eXBlLWNoaWxkcmVuIG5hbWUpKSB0
ICJUeXBlIGhhcyBjaGlsZHJlbjogJVMiKQogIDs7IENsZWFyIGNhY2hlZCB2YWx1ZSBvZiBz
cGVjaWFsaXplcnMgd2l0aCBOQU1FLgogIChndHlwZS0tcmVzZXQtc3BlY2lhbGl6ZXJzIG5h
bWUpCiAgKGNsLXJlbXByb3AgbmFtZSAnZ3R5cGUtLXNlcW4pCiAgKGNsLXJlbXByb3AgbmFt
ZSAnY2wtLWNsYXNzKQogIChjbC1yZW1wcm9wIG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcikK
ICAoc2V0cSBndHlwZS0tbGlzdCAoZGVscSBuYW1lIGd0eXBlLS1saXN0KSkKICBuaWwpCgo7
OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gZGVmZ3R5cGUgKG5hbWUgJm9wdGlvbmFsIHBhcmVu
dHMgJnJlc3QgYXJncykKICAiRGVmaW5lIE5BTUUgYXMgYSBndHlwZSB0aGF0IGluaGVyaXRz
IGZyb20gUEFSRU5UUy4KSWYgYSBndHlwZSB3aXRoIE5BTUUgYWxyZWFkeSBleGlzdHMsIHJl
cGxhY2UgaXQuCgpOQU1FIGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBn
dHlwZS4KCk9wdGlvbmFsIGFyZ3VtZW50IFBBUkVOVFMgaXMgZWl0aGVyIGFuIHVucXVvdGVk
IHN5bWJvbCBvciBsaXN0IG9mCnN5bWJvbHMgb3RoZXIgdGhhbiBOQU1FIHJlcHJlc2VudGlu
ZyB0eXBlcyBwYXJlbnRzIG9mIE5BTUUuClBBUkVOVFMgbmlsIG9yIG9taXR0ZWQgbWVhbnMg
dGhhdCBOQU1FIGlzIGEgcm9vdCB0eXBlLgoKQWxzbyBwYXNzIE5BTUUgYW5kIEFSR1MgdG8g
YGNsLWRlZnR5cGUnIHRvIGRlZmluZSBOQU1FIGFzIGEgbmV3IGRhdGEKdHlwZS4iCiAgKGRl
Y2xhcmUgKGRlYnVnIGNsLWRlZm1hY3JvKSAoZG9jLXN0cmluZyA0KSAoaW5kZW50IDMpKQog
IChjbC13aXRoLWdlbnN5bXMgKGVycikKICAgIGAoY29uZGl0aW9uLWNhc2UgLGVycgogICAg
ICAgICAocHJvZ24KICAgICAgICAgICAoY2wtZGVmdHlwZSAsbmFtZSAsQGFyZ3MpCiAgICAg
ICAgICAgKGd0eXBlLS1yZWdpc3RlciAnLG5hbWUgJyxwYXJlbnRzICcsYXJncykpCiAgICAg
ICAoZXJyb3IKICAgICAgICAoZ3R5cGUtLXVucmVnaXN0ZXIgJyxuYW1lKQogICAgICAgIChl
cnJvciAoZXJyb3ItbWVzc2FnZS1zdHJpbmcgLGVycikpKSkpKQoKKGRlZm1hY3JvIHJlbWd0
eXBlIChuYW1lKQogICJSZW1vdmUgdGhlIGd0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1
bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEgZ3R5cGUuClNpZ25hbCBhbiBlcnJvciBp
ZiBvdGhlciBndHlwZXMgaW5oZXJpdCBmcm9tIE5BTUUuIgogIGAocHJvZ24KICAgICAoY2wt
Y2hlY2stdHlwZSAnLG5hbWUgKHNhdGlzZmllcyBndHlwZS1wKSkKICAgICAoZ3R5cGUtLXVu
cmVnaXN0ZXIgJyxuYW1lKSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVu
ZGxlc3MgcmVjdXJzaW9uIGluICdndHlwZS1vZicuCihkZWZ2YXIgZ3R5cGUtLW9iamVjdCAo
bWFrZS1zeW1ib2wgInZvaWQiKSkKOzsgRWFjaCBndHlwZSBtdXN0IHNhdGlzZmllcyBgZXFs
Jy4KKGRlZnZhciBndHlwZS0tdW5pcXVlIChtYWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxdWFs
KQogICJSZWNvcmQgYW4gdW5pcXVlIHZhbHVlIGZvciBlYWNoIGd0eXBlLiIpCgooZGVmdW4g
Z3R5cGUtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSBtb3N0IHNwZWNpZmljIHBvc3NpYmxl
IGd0eXBlIE9CSkVDVCBiZWxvbmdzIHRvLgpSZXR1cm4gYW4gdW5pcXVlIGxpc3Qgb2YgdHlw
ZXMgT0JKRUNUIGJlbG9uZ3MgdG8sIG9yZGVyZWQgZnJvbSB0aGUKbW9zdCBzcGVjaWZpYyB0
eXBlIHRvIHRoZSBtb3N0IGdlbmVyYWwuIgogIDs7IElnbm9yZSByZWN1cnNpdmUgY2FsbCBv
biB0aGUgc2FtZSBPQkpFQ1QsIHdoaWNoIGNhbiBsZWdpdGltYXRlbHkKICA7OyBvY2N1ciB3
aGVuLCBmb3IgZXhhbXBsZSwgYSBwYXJlbnQgdHlwZSBpcyBpbnZlc3RpZ2F0aW5nIHdoZXRo
ZXIKICA7OyBhbiBvYmplY3QncyB0eXBlIGlzIHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJl
bi4KICAodW5sZXNzIChlcSBvYmplY3QgZ3R5cGUtLW9iamVjdCkKICAgIChsZXQgKChndHlw
ZS0tb2JqZWN0IG9iamVjdCkKICAgICAgICAgIChmb3VuZCAobGlzdCAoY2wtdHlwZS1vZiBv
YmplY3QpKSkpCiAgICAgIDs7IENvbGxlY3QgYWxsIGd0eXBlcyBPQkpFQ1QgYmVsb25ncyB0
by4KICAgICAgKGRvbGlzdCAoZ3R5cGUgZ3R5cGUtLWxpc3QpCiAgICAgICAgKGlmIChjbC10
eXBlcCBvYmplY3QgZ3R5cGUpCiAgICAgICAgICAgIChwdXNoIGd0eXBlIGZvdW5kKSkpCiAg
ICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUgb2YgdHlwZS4KICAgICAgKHdpdGgtbWVt
b2l6YXRpb24gKGdldGhhc2ggZm91bmQgZ3R5cGUtLXVuaXF1ZSkKICAgICAgICBmb3VuZCkp
KSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGRlZnZhciBndHlwZS0tc3BlY2lhbGl6
ZXJzIChtYWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxKQogICJNZW1vaXplIGd0eXBlIHNwZWNp
YWxpemVycy4KVGhpcyBjYWNoZSBpcyBjbGVhcmVkIGJ5IGBndHlwZS0tcmVnaXN0ZXInIGFu
ZCBgZ3R5cGUtLXVucmVnaXN0ZXInLiIpCgooZGVmdW4gZ3R5cGUtLXJlc2V0LXNwZWNpYWxp
emVycyAobmFtZSkKICAiUmVtb3ZlIGFsbCBjYWNoZWQgdmFsdWUgb2Ygc3BlY2lhbGl6ZXJz
IHdpdGggTkFNRS4iCiAgKG1hcGhhc2ggKGxhbWJkYSAoa2V5IF8pCiAgICAgICAgICAgICAo
aWYgKG1lbXEgbmFtZSBrZXkpCiAgICAgICAgICAgICAgICAgKHJlbWhhc2gga2V5IGd0eXBl
LS1zcGVjaWFsaXplcnMpKSkKICAgICAgICAgICBndHlwZS0tc3BlY2lhbGl6ZXJzKSkKCihk
ZWZ1biBndHlwZS0tc3BlY2lhbGl6ZXJzICh0YWcgJnJlc3QgXykKICAiSWYgVEFHIGlzIGEg
Z3R5cGUsIHJldHVybiBpdHMgc3BlY2lhbGl6ZXJzLiIKICAoYW5kIChjb25zcCB0YWcpIChn
dHlwZS1wIChjYXIgdGFnKSkKICAgICAgICh3aXRoLW1lbW9pemF0aW9uIChnZXRoYXNoIHRh
ZyBndHlwZS0tc3BlY2lhbGl6ZXJzKQogICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cyAo
bWFwY2FyICMnZ3R5cGUtcGFyZW50cyB0YWcpKSkpKQoKKGNsLWdlbmVyaWMtZGVmaW5lLWdl
bmVyYWxpemVyIGd0eXBlLS1nZW5lcmFsaXplcgogIDIwIDs7ICJ0eXBlb2YiIHByaW9yaXR5
IDwgImd0eXBlLW9mIiBwcmlvcml0eSA8ICJoZWFkIiBwcmlvcml0eQogIChsYW1iZGEgKG9i
aiAmcmVzdCBfKSBgKGd0eXBlLW9mICxvYmopKQogICMnZ3R5cGUtLXNwZWNpYWxpemVycykK
CihjbC1kZWZtZXRob2QgY2wtZ2VuZXJpYy1nZW5lcmFsaXplcnMgOmV4dHJhICJndHlwZS1v
ZiIgKHR5cGUpCiAgIlN1cHBvcnQgZm9yIGRpc3BhdGNoIG9uIGd0eXBlcy4iCiAgKGlmIChn
dHlwZS1wIHR5cGUpCiAgICAgIChsaXN0IGd0eXBlLS1nZW5lcmFsaXplcikKICAgIChjbC1j
YWxsLW5leHQtbWV0aG9kKSkpCgoocHJvdmlkZSAnZ3R5cGUpCgo7OzsgZ3R5cGUuZWwgZW5k
cyBoZXJlCg==
--------------NqVnDj0IabAnTmcUIWM0h849--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Apr 2025 18:28:02 +0000
Resent-Message-ID: <handler.77725.B77725.17446552329889 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17446552329889
(code B ref 77725); Mon, 14 Apr 2025 18:28:02 +0000
Received: (at 77725) by debbugs.gnu.org; 14 Apr 2025 18:27:12 +0000
Received: from localhost ([127.0.0.1]:48946 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4OWW-0002ZQ-5M
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 14:27:12 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47983)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u4OWS-0002ZB-Oa
for 77725 <at> debbugs.gnu.org; Mon, 14 Apr 2025 14:27:09 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3FB9D80860;
Mon, 14 Apr 2025 14:27:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744655221;
bh=QCL8PHb28WMr+cpFsspVXKxD74FdIj0XF6kwv20eQts=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=QH41ooHBgLOvpCcScTqwG3HllciIxWdceVO2W/Xhrdqfn8wNQGHN2wwq+4mMwEbRc
gDfBy1b1G2eZJniGdz5/7/rahoJ1PcJ30Q6lh63a1RMxiiS1BaBaVOPp+DCcw0iXgP
/REZ9Ynds8puLC2P+rwo37m/IQ4qmODWydWYF+TIaiy2mil+bNaE0ms2ciYmK+rQ4b
S3BMd69uZfaPl9V3nbxALX09RrxX266lzE1MZfBJHIhnzZpWWq/Q6ceU5lK9Ts+613
kwYwkgRWrwaX6Nsm9MH/3+U3RoGBYcUUfZ+ATHacMuAYk2jVzMZFZR8d+Q9yc3p1Se
ki32u/s7zEs1A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 35CF280644;
Mon, 14 Apr 2025 14:27:01 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0F689120550;
Mon, 14 Apr 2025 14:27:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
Message-ID: <jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
Date: Mon, 14 Apr 2025 14:27:00 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.184 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> I understand more how cl-generic works, and I reworked gtype.el
> (attached) according to your inputs and my better understanding.
Looks good, thanks.
Some comments below.
> (eval-when-compile (require 'cl-macs)) ;For cl--find-class.
You can also use `cl-find-class` which doesn't require this gymnastics.
> (define-inline gtype-p (object)
> "Return non-nil if the type of OBJECT is a gtype."
> (inline-letevals (object)
> (inline-quote
> (and (symbolp ,object)
> (eq (type-of (cl--find-class ,object)) 'gtype-class)))))
I hope this function is not speed-critical (and so can be a plain `defun`).
> (define-inline gtype-parents (name)
> "Get parents of type with NAME.
> NAME is a symbol representing a type.
> Return a possibly empty list of types."
> (inline-quote
> (cl--class-allparents (cl--find-class ,name))))
Same here.
> (defun gtype--topologic-sort (graph &optional tie-breaker)
How is this different from `merge-ordered-lists`?
> ;;;###autoload
> (defmacro defgtype (name &optional parents &rest args)
> "Define NAME as a gtype that inherits from PARENTS.
Inheritance !=3D subtyping. Better stick to the term "subtype" here since
there doesn't seem to be any inheritance going on here.
> If a gtype with NAME already exists, replace it.
>
> NAME is an unquoted symbol representing a gtype.
>
> Optional argument PARENTS is either an unquoted symbol or list of
> symbols other than NAME representing types parents of NAME.
> PARENTS nil or omitted means that NAME is a root type.
>
> Also pass NAME and ARGS to `cl-deftype' to define NAME as a new data
> type."
I get the impression that the role/impact of PARENTS is not explained
clearly enough. The explanation should be clear enough that the reader
can infer more or less what could happen if a parent is missing or if
a non-parent is incorrectly listed as a parent.
> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
> (cl-with-gensyms (err)
> `(condition-case ,err
> (progn
> (cl-deftype ,name ,@args)
> (gtype--register ',name ',parents ',args))
> (error
> (gtype--unregister ',name)
> (error (error-message-string ,err))))))
Could we merge this into `cl-deftype`?
> (defmacro remgtype (name)
Try and stay within the namespace prefix.
> (defun gtype-of (object)
> "Return the most specific possible gtype OBJECT belongs to.
> Return an unique list of types OBJECT belongs to, ordered from the
> most specific type to the most general."
> ;; Ignore recursive call on the same OBJECT, which can legitimately
> ;; occur when, for example, a parent type is investigating whether
> ;; an object's type is that of one of its children.
> (unless (eq object gtype--object)
> (let ((gtype--object object)
> (found (list (cl-type-of object))))
> ;; Collect all gtypes OBJECT belongs to.
> (dolist (gtype gtype--list)
> (if (cl-typep object gtype)
> (push gtype found)))
> ;; Return an unique value of type.
> (with-memoization (gethash found gtype--unique)
> found))))
Since `gtype-of` is the function used to get the "tagcode" used for
method-dispatch, it is speed-critical.
But the above looks rather costly. =F0=9F=99=81
I think we could reduce this problem significantly with reasonably
simple changes to `cl-generic`: we could provide to the TAGCODE-FUNCTION
the list of specializers used by methods of the current
generic-function, so we'd only need to check those types which are
actually useful for the current dispatch.
[ Hmm... well, maybe not completely "simple" since it might have
some problematic impact on the `cl--generic-prefill-dispatchers`
mechanism, but that should be solvable. ]
> (defun gtype--specializers (tag &rest _)
> "If TAG is a gtype, return its specializers."
> (and (consp tag) (gtype-p (car tag))
> (with-memoization (gethash tag gtype--specializers)
> (merge-ordered-lists (mapcar #'gtype-parents tag)))))
AFAIK this function is only ever called with "tagcodes" returned by your
own TAGCODE-FUNCTION, so I think the `gtype-p` test is redundant.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 15 Apr 2025 09:32:02 +0000
Resent-Message-ID: <handler.77725.B77725.174470947419967 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174470947419967
(code B ref 77725); Tue, 15 Apr 2025 09:32:02 +0000
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 09:31:14 +0000
Received: from localhost ([127.0.0.1]:50695 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4cdN-0005By-Dv
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 05:31:14 -0400
Received: from smtp-26.smtpout.orange.fr ([80.12.242.26]:35423
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u4cdG-0005BP-5w
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 05:31:09 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 4cd8u3VVA2zsA4cdCuBLLG; Tue, 15 Apr 2025 11:31:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744709464;
bh=onn+OKbV2YH2sALAUPnMKhfmSN2BOFCacNtvU2p3DY8=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=fiAIOoKq/shXPEEjY6t2pCTEof4yRgskTeuVMzvLee27/5L/xC0JWn4wMh2kx5+tp
1HKdqDXdieYyqytSd6T7yOr/1S49eYM/ulOu5iuFlvLUy/pD4NVpGZWYOpTSV8mQ+O
DwzEkH4EU/0TWBN1t/T6HIe739/T7y2guperiguR9KmP8K42sXt2DGr2243ag1m/Bo
H6a0jaTgfFweHbv3XemNpQGXT7H/nZPKUxD7rg6OLE3nh0Dr/+IBP+Tnv6tCI65S9U
XA5q48mDw+CeD4R1QGeeETrxtK3gjpAnPaQwF+6/8/5aLlZ4aV13kVCHSNVxy0jdqP
V6mpbOEYzCv4A==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Tue, 15 Apr 2025 11:31:04 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------VcIOq35tljgy1x8KnkSj0iEX"
Message-ID: <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
Date: Tue, 15 Apr 2025 11:30:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------VcIOq35tljgy1x8KnkSj0iEX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2025-04-14 20:27, Stefan Monnier wrote:
>> I understand more how cl-generic works, and I reworked gtype.el
>> (attached) according to your inputs and my better understanding.
>
> Looks good, thanks.
Thank you for your review! My answers below.
>> (eval-when-compile (require 'cl-macs)) ;For cl--find-class.
>
> You can also use `cl-find-class` which doesn't require this gymnastics.
Done. I didn't know about this public version of `cl--find-class'.
However, as it seems not possible to write:
`(setf (cl-find-class object) value)'
I had to use `put' instead in one place in `gtype--register'.
>> (define-inline gtype-p (object)
>> "Return non-nil if the type of OBJECT is a gtype."
>> (inline-letevals (object)
>> (inline-quote
>> (and (symbolp ,object)
>> (eq (type-of (cl--find-class ,object)) 'gtype-class)))))
>
> I hope this function is not speed-critical (and so can be a plain `defun`).
>
>> (define-inline gtype-parents (name)
>> "Get parents of type with NAME.
>> NAME is a symbol representing a type.
>> Return a possibly empty list of types."
>> (inline-quote
>> (cl--class-allparents (cl--find-class ,name))))
>
> Same here.
Done. I didn't notice any significant impact on performance :-)
>> (defun gtype--topologic-sort (graph &optional tie-breaker)
>
> How is this different from `merge-ordered-lists`?
The result of the two functions are slightly different but seems
consistent, so I switched to `merge-ordered-lists'.
>> ;;;###autoload
>> (defmacro defgtype (name &optional parents &rest args)
>> "Define NAME as a gtype that inherits from PARENTS.
>
> Inheritance != subtyping. Better stick to the term "subtype" here since
> there doesn't seem to be any inheritance going on here.
Done.
> I get the impression that the role/impact of PARENTS is not explained
> clearly enough. The explanation should be clear enough that the reader
> can infer more or less what could happen if a parent is missing or if
> a non-parent is incorrectly listed as a parent.
This is a very good point. Currently, the role of PARENTS is limited
to specify in which order gtype `gtype-of' will check gtypes.
This order is not automatically transposed to the type specifier of
`cl-deftype'. And there is a risk of inconsistency here.
For instance, you can do something like this:
(defgtype a-fixnum nil ()
'fixnum)
(gtype-of 10)
(a-fixnum fixnum)
(defgtype a-fixnum-between-1-10 a-fixnum ()
`(satisfies ,(lambda (x) (and (numberp x) (> x 0) (< x 11)))))
(gtype-of 10.1)
(a-fixnum-between-1-10 float)
gtype--list
(a-fixnum-between-1-10 a-fixnum)
Clearly 10.1 is not "a-fixnum-between-1-10", because the type
specifier is incorrect; even if `a-fixnum-between-1-10' is a subtype
of `a-fixnum'.
The correct subtype could be:
(defgtype a-fixnum-between-1-10 a-fixnum ()
`(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
But the type specifier is not produced automatically.
Not so easy to put all this in a docstring. Any idea?
>> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
>> (cl-with-gensyms (err)
>> `(condition-case ,err
>> (progn
>> (cl-deftype ,name ,@args)
>> (gtype--register ',name ',parents ',args))
>> (error
>> (gtype--unregister ',name)
>> (error (error-message-string ,err))))))
>
> Could we merge this into `cl-deftype`?
That would be great. But I need some help here to correctly dispatch
all functions in gtype to Emacs libraries: cl-macs, cl-generic ? May
be in this case, gtype should be moved to the cl namespace too.
Or do you envision something different?
>> (defmacro remgtype (name)
>
> Try and stay within the namespace prefix.
Renamed to `gtype-remove'.
>> (defun gtype-of (object)
>> "Return the most specific possible gtype OBJECT belongs to.
>> Return an unique list of types OBJECT belongs to, ordered from the
>> most specific type to the most general."
>> ;; Ignore recursive call on the same OBJECT, which can legitimately
>> ;; occur when, for example, a parent type is investigating whether
>> ;; an object's type is that of one of its children.
>> (unless (eq object gtype--object)
>> (let ((gtype--object object)
>> (found (list (cl-type-of object))))
>> ;; Collect all gtypes OBJECT belongs to.
>> (dolist (gtype gtype--list)
>> (if (cl-typep object gtype)
>> (push gtype found)))
>> ;; Return an unique value of type.
>> (with-memoization (gethash found gtype--unique)
>> found))))
>
> Since `gtype-of` is the function used to get the "tagcode" used for
> method-dispatch, it is speed-critical.
I agree.
> But the above looks rather costly. 🙁
emacs -Q on my laptop:
Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
Memory: 15,5 GiB of RAM
consistently takes around 1 millisecond to check 2000 gtypes, which
seems not so bad.
Here is the benchmark I use:
(defgtype cons-car-foo nil ()
"A cons with a `foo' car."
`(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
(defgtype cons-cdr-foo nil ()
"A cons with a `foo' cdr."
`(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
(gtype-of '(foo . foo))
=> (cons-car-foo cons-cdr-foo cons)
;; Create a very long list of gtypes that gtype-of will check
;; sequentially.
(let* ((count 2000)
(gtype--list (let ((list '(cons-cdr-foo)))
(dotimes (_ count)
(push 'cons-car-foo list))
list))
(object '(foo . foo))
(runs 1))
(garbage-collect)
(benchmark-run
(gtype-of object)
runs))
=>(0.00107773 0 0.0)
> I think we could reduce this problem significantly with reasonably
> simple changes to `cl-generic`: we could provide to the TAGCODE-FUNCTION
> the list of specializers used by methods of the current
> generic-function, so we'd only need to check those types which are
> actually useful for the current dispatch.
> [ Hmm... well, maybe not completely "simple" since it might have
> some problematic impact on the `cl--generic-prefill-dispatchers`
> mechanism, but that should be solvable. ]
I am afraid, this looks beyond my knowledge of cl-generic.
>> (defun gtype--specializers (tag &rest _)
>> "If TAG is a gtype, return its specializers."
>> (and (consp tag) (gtype-p (car tag))
>> (with-memoization (gethash tag gtype--specializers)
>> (merge-ordered-lists (mapcar #'gtype-parents tag)))))
>
> AFAIK this function is only ever called with "tagcodes" returned by your
> own TAGCODE-FUNCTION, so I think the `gtype-p` test is redundant.
Good find. Done.
Please find attached the last version.
David
--------------VcIOq35tljgy1x8KnkSj0iEX
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el"
Content-Disposition: attachment; filename="gtype.el"
Content-Transfer-Encoding: base64
Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g
bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u
Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50
YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw
cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg
cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl
ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m
IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg
UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs
b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv
bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k
cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg
ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg
dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcyAoc2Vl
IGFsc28gQnVnIzc3NzI1IGF0Cjs7IDxodHRwczovL2RlYmJ1Z3MuZ251Lm9yZy9jZ2kvYnVn
cmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFy
ZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1hY3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7
Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rpb24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9m
IGFuIG9iamVjdC4KOzsKOzsgLSBgZ3R5cGUtcmVtb3ZlJywgYSBtYWNybyB0aGF0IHJlbW92
ZXMgYSBndHlwZS4KOzsKOzsgQSB0cml2aWFsIGV4YW1wbGU6Cjs7Cjs7IChkZWZndHlwZSBu
ZWdhdGl2ZSBuaWwgKCkKOzsgICAiQSBuZWdhdGl2ZSBudW1iZXIiCjs7ICAgJyhhbmQgbnVt
YmVyIChzYXRpc2ZpZXMgbWludXNwKSkpCjs7Cjs7IChkZWZndHlwZSB6ZXJvIG5pbCAoKQo7
OyAgICJBIHplcm8gbnVtYmVyIgo7OyAgICcoYW5kIG51bWJlciAoc2F0aXNmaWVzIHplcm9w
KSkpCjs7Cjs7IChkZWZndHlwZSBwb3NpdGl2ZSBuaWwgKCkKOzsgICAiQSBwb3NpdGl2ZSBu
dW1iZXIiCjs7ICAgJyhhbmQgbnVtYmVyIChzYXRpc2ZpZXMgcGx1c3ApKSkKOzsKOzsgKGNs
LWRlZm1ldGhvZCB0ZXN0LW51bWJlciAoKG4gbmVnYXRpdmUpKQo7OyAgIChmb3JtYXQgIm5l
Z2F0aXZlIG51bWJlciwgJXMiIG4pKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVy
ICgobiB6ZXJvKSkKOzsgICAoZm9ybWF0ICJ6ZXJvIG51bWJlciwgJXMiIG4pKQo7Owo7OyAo
Y2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBwb3NpdGl2ZSkpCjs7ICAgKGZvcm1hdCAi
cG9zaXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7ICh0ZXN0LW51bWJlciAtMTIzLjApCjs7
ID0+ICJuZWdhdGl2ZSBudW1iZXIsIC0xMjMuMCIKOzsgKHRlc3QtbnVtYmVyIChhYnMgLTEy
My4wKSkKOzsgPT4gInBvc2l0aXZlIG51bWJlciwgMTIzLjAiCjs7ICh0ZXN0LW51bWJlciAo
cm91bmQgMC4wMDAwMDAwMDAwMDEpKQo7OyA9PiAiemVybyBudW1iZXIsIDAiCjs7Cjs7IFBl
cmZvcm1hbmNlIGNvbnNpZGVyYXRpb25zOgo7Owo7OyBUaGUgY3JpdGljYWwgcG9pbnQgb2Yg
dGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaXMgdGhlIGZ1bmN0aW9uCjs7IGBndHlwZS1v
Zicgd2hpY2ggc2VxdWVudGlhbGx5IHRyaWVzIGFsbCBrbm93biBndHlwZXMgdG8gY29sbGVj
dCBhbGwKOzsgdGhvc2UgYW4gb2JqZWN0IGJlbG9uZ3MgdG8sIGZyb20gdGhlIG1vc3Qgc3Bl
Y2lmaWMgdG8gdGhlIG1vc3QKOzsgZ2VuZXJhbCB0eXBlLiAgVGhlcmVmb3JlLCB0aGUgbWF4
aW11bSB0aW1lIHRvIGZpbmQgYW4gb2JqZWN0J3MgdHlwZQo7OyBkaXJlY3RseSBkZXBlbmRz
IG9uIHRoZSBudW1iZXIgb2YgZ3R5cGVzLiAgSXMgdGhlcmUgYSBiZXR0ZXIKOzsgc29sdXRp
b24/ICBBbnl3YXksIGFzc3VtaW5nIHRoYXQgZWFjaCBzaW5nbGUgdGVzdCB0byBrbm93IHdo
ZXRoZXIKOzsgYW4gb2JqZWN0IGlzIG9mIGEgZ2l2ZW4gZ3R5cGUgaXMgcmVhc29uYWJseSBm
YXN0LCB0aGUgcGVyZm9ybWFuY2UKOzsgb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBzZWVtcyBh
Y2NlcHRhYmxlIChiYXNlZCBvbiB0aGUgdHJpdmlhbAo7OyBleGFtcGxlIGFib3ZlLCBhdHRl
bXB0aW5nIDEsMDAwIGd0eXBlIGNoZWNrcyB0YWtlcyBhYm91dCBoYWxmIGEKOzsgbWlsbGlz
ZWNvbmQgb24gbXkgc2V0dXApLgo7OwoKOzs7IENvZGU6Cjs7CihyZXF1aXJlICdjbC1saWIp
CgooZGVmdmFyIGd0eXBlLS1saXN0IG5pbAogICJQcmVjZWRlbmNlIGxpc3Qgb2YgdGhlIGRl
ZmluZWQgZ3R5cGVzLiIpCgooZGVmdW4gZ3R5cGUtcCAob2JqZWN0KQogICJSZXR1cm4gbm9u
LW5pbCBpZiB0aGUgdHlwZSBvZiBPQkpFQ1QgaXMgYSBndHlwZS4iCiAgKGFuZCAoc3ltYm9s
cCBvYmplY3QpCiAgICAgICAoZXEgKHR5cGUtb2YgKGNsLWZpbmQtY2xhc3Mgb2JqZWN0KSkg
J2d0eXBlLWNsYXNzKSkpCgooY2wtZGVmc3RydWN0CiAgICAoZ3R5cGUtY2xhc3MKICAgICAo
OmluY2x1ZGUgY2wtLWNsYXNzKQogICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVj
dG9yIG5pbCkKICAgICAoOmNvbnN0cnVjdG9yIGd0eXBlLS1jbGFzcy1tYWtlCiAgICAgICAg
ICAgICAgICAgICAobmFtZQogICAgICAgICAgICAgICAgICAgIGRvY3N0cmluZwogICAgICAg
ICAgICAgICAgICAgIHBhcmVudC10eXBlcwogICAgICAgICAgICAgICAgICAgICZhdXggKHBh
cmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChsYW1iZGEgKHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGNsLWNoZWNrLXR5cGUgdHlwZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChjbC1maW5kLWNsYXNzIHR5cGUpKQogICAgICAgICAgICAg
ICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAi
VHlwZSBkZXNjcmlwdG9ycyBmb3IgZ3R5cGVzLiIpCgooZGVmdW4gZ3R5cGUtcGFyZW50cyAo
bmFtZSkKICAiR2V0IHBhcmVudHMgb2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1i
b2wgcmVwcmVzZW50aW5nIGEgdHlwZS4iCiAgKGNsLS1jbGFzcy1hbGxwYXJlbnRzIChjbC1m
aW5kLWNsYXNzIG5hbWUpKSkKCihkZWZ1biBndHlwZS1jaGlsZHJlbiAobmFtZSkKICAiR2V0
IGNoaWxkcmVuIG9mIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVw
cmVzZW50aW5nIGEgZ3R5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlw
ZXMuIgogIChjbC1jaGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBndHlwZS1wKSkKICAobGV0
IChjaGlsZHJlbikKICAgIChkb2xpc3QgKGVsdCBndHlwZS0tbGlzdCkKICAgICAgKG9yIChl
cSBuYW1lIGVsdCkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIChndHlwZS1wYXJlbnRzIGVs
dCkpCiAgICAgICAgICAgICAgKHB1c2ggZWx0IGNoaWxkcmVuKSkpKQogICAgY2hpbGRyZW4p
KQoKKGRlZnVuIGd0eXBlLS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxpc3Qg
b2YgZGVmaW5lZCBndHlwZXMuIgogIChjbC1sYWJlbHMgKChhbGxwYXJlbnRzIChjbGFzcykK
ICAgICAgICAgICAgICAgIChsZXQgKCh0eXBlIChjbC0tY2xhc3MtbmFtZSBjbGFzcykpKQog
ICAgICAgICAgICAgICAgICA7OyBFeGNsdWRlIG5vbi1ndHlwZXMgZnJvbSB0aGUgREFHLiAg
YGd0eXBlLW9mJwogICAgICAgICAgICAgICAgICA7OyBkb2Vzbid0IGNoZWNrIG5vbi1ndHlw
ZXMgYXQgcnVuIHRpbWUsIHRoZXkgYXJlCiAgICAgICAgICAgICAgICAgIDs7IGhhbmRsZWQg
YnkgdGhlICJ0eXBlLW9mIiBnZW5lcmFsaXplci4KICAgICAgICAgICAgICAgICAgKGlmIChn
dHlwZS1wIHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAoY29ucyB0eXBlCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChtYXBjYXIgIydhbGxwYXJlbnRzCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAoY2wtLWNsYXNzLXBhcmVudHMgY2xhc3MpKSkpKSkpKQog
ICAgKG1hcGNhciAobGFtYmRhIChndHlwZSkgKGFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNz
IGd0eXBlKSkpCiAgICAgICAgICAgIGd0eXBlLS1saXN0KSkpCgooZGVmdW4gZ3R5cGUtLXJl
Z2lzdGVyIChuYW1lICZvcHRpb25hbCBwYXJlbnRzIGFyZ3MpCiAgIlJlZ2lzdGVyIGEgZ3R5
cGUgd2l0aCBOQU1FIGFuZCBQQVJFTlRTLgpBUkdTIGFyZSB0aG9zZSB0aGF0IHdpbGwgYmUg
cGFzc2VkIHRvIGBjbC1kZWZ0eXBlJy4iCiAgKGNvbmRpdGlvbi1jYXNlIGVycgogICAgICAo
bGV0ICgoY2xhc3MgKGNsLWZpbmQtY2xhc3MgbmFtZSkpCiAgICAgICAgICAgIChyZWdlZCAo
bWVtcSBuYW1lIGd0eXBlLS1saXN0KSkpCiAgICAgICAgKGlmIChudWxsIGNsYXNzKQogICAg
ICAgICAgICAob3IgKG51bGwgcmVnZWQpCiAgICAgICAgICAgICAgICAoZXJyb3IgIk5ldyB0
eXBlLCBidXQgYWxyZWFkeSBpbiBndHlwZXMgbGlzdCIpKQogICAgICAgICAgKG9yIHJlZ2Vk
ICJFeGlzdGluZyB0eXBlLCBidXQgbm90IGluIGd0eXBlcyBsaXN0IikKICAgICAgICAgIChv
ciAoZXEgKHR5cGUtb2YgY2xhc3MpICdndHlwZS1jbGFzcykKICAgICAgICAgICAgICAoZXJy
b3IgIlR5cGUgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNsYXNzKSkpKQogICAg
ICAgIChvciAobGlzdHAgcGFyZW50cykgKHNldHEgcGFyZW50cyAobGlzdCBwYXJlbnRzKSkp
CiAgICAgICAgKGlmIChtZW1xIG5hbWUgcGFyZW50cykKICAgICAgICAgICAgKGVycm9yICJU
eXBlIGluIHBhcmVudHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICA7OyBTZXR1cCBhIHR5cGUg
ZGVzY3JpcHRvciBmb3IgTkFNRSwgd2l0aCBQQVJFTlRTIGFuZCB0aGUKICAgICAgICA7OyBk
b2NzdHJpbmcgcG9zc2libHkgcHJlc2VudCBpbiBBUkdTLgogICAgICAgIChsZXQgKChkb2Nz
dHJpbmcgKGNhYXIgKG1hY3JvZXhwLXBhcnNlLWJvZHkgKGNkciBhcmdzKSkpKSkKICAgICAg
ICAgIChvciAoc3RyaW5ncCBkb2NzdHJpbmcpIChzZXRxIGRvY3N0cmluZyBuaWwpKQogICAg
ICAgICAgKHB1dCBuYW1lICdjbC0tY2xhc3MKICAgICAgICAgICAgICAgKGd0eXBlLS1jbGFz
cy1tYWtlIG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKSkKICAgICAgICAoaWYgY2xhc3MKICAg
ICAgICAgICAgOzsgQ2xlYXIgY2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVycyB3aXRoIE5B
TUUuCiAgICAgICAgICAgIChndHlwZS0tcmVzZXQtc3BlY2lhbGl6ZXJzIG5hbWUpCiAgICAg
ICAgICA7OyBSZWNvcmQgdGhlIG5ldyB0eXBlLgogICAgICAgICAgKHB1c2ggbmFtZSBndHlw
ZS0tbGlzdCkpCiAgICAgICAgOzsgVG8gZmluZCB0aGUgbW9zdCBwb3NzaWJsZSBzcGVjaWZp
YyBndHlwZSBvZiBhbiBvYmplY3QsIG1vc3QKICAgICAgICA7OyBzcGVjaWZpYyB0eXBlcyBt
dXN0IGJlIHRyaWVkIGJlZm9yZSBtb3JlIGdlbmVyYWwgdHlwZXMuCiAgICAgICAgKHNldHEg
Z3R5cGUtLWxpc3QgKG1lcmdlLW9yZGVyZWQtbGlzdHMgKGd0eXBlLS1kYWcpKSkKICAgICAg
ICBuYW1lKQogICAgKGVycm9yCiAgICAgKGd0eXBlLS11bnJlZ2lzdGVyIG5hbWUpCiAgICAg
KGVycm9yIChmb3JtYXQgIiVzLCAlUyIgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikgbmFt
ZSkpKSkpCgooZGVmdW4gZ3R5cGUtLXVucmVnaXN0ZXIgKG5hbWUpCiAgIlVucmVnaXN0ZXIg
dGhlIGd0eXBlIHdpdGggTkFNRS4iCiAgKHdoZW4tbGV0KiAoKGNoaWxkcmVuIChhbmQgKGd0
eXBlLXAgbmFtZSkgKGd0eXBlLWNoaWxkcmVuIG5hbWUpKSkpCiAgICAoZXJyb3IgIlR5cGUg
aGFzIGNoaWxkcmVuOiAlUyIgY2hpbGRyZW4pKQogIDs7IENsZWFyIGNhY2hlZCB2YWx1ZSBv
ZiBzcGVjaWFsaXplcnMgd2l0aCBOQU1FLgogIChndHlwZS0tcmVzZXQtc3BlY2lhbGl6ZXJz
IG5hbWUpCiAgKGNsLXJlbXByb3AgbmFtZSAnZ3R5cGUtLXNlcW4pCiAgKGNsLXJlbXByb3Ag
bmFtZSAnY2wtLWNsYXNzKQogIChjbC1yZW1wcm9wIG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxl
cikKICAoc2V0cSBndHlwZS0tbGlzdCAoZGVscSBuYW1lIGd0eXBlLS1saXN0KSkKICBuaWwp
Cgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gZGVmZ3R5cGUgKG5hbWUgJm9wdGlvbmFsIHBh
cmVudHMgJnJlc3QgYXJncykKICAiRGVmaW5lIE5BTUUgYXMgYSBndHlwZSwgc3VidHlwZSBv
ZiBQQVJFTlRTIGd0eXBlcy4KSWYgYSBndHlwZSB3aXRoIE5BTUUgYWxyZWFkeSBleGlzdHMs
IHJlZGVmaW5lIGl0LiAgT24gZXJyb3IsIE5BTUUgaXMKbm8gbW9yZSBkZWZpbmVkIGFzIGEg
Z3R5cGUuCgpOQU1FIGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBndHlw
ZS4KCk9wdGlvbmFsIGFyZ3VtZW50IFBBUkVOVFMgaXMgZWl0aGVyIGFuIHVucXVvdGVkIHN5
bWJvbCBvciBsaXN0IG9mCnN5bWJvbHMgb3RoZXIgdGhhbiBOQU1FIHJlcHJlc2VudGluZyBn
dHlwZXMgd2hvc2UgTkFNRSBpcyBhIHN1YnR5cGUuCgpBbHNvIHBhc3MgTkFNRSBhbmQgQVJH
UyB0byBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIE5BTUUgYXMgYSBuZXcgZGF0YQp0eXBlLiIK
ICAoZGVjbGFyZSAoZGVidWcgY2wtZGVmbWFjcm8pIChkb2Mtc3RyaW5nIDQpIChpbmRlbnQg
MykpCiAgYChwcm9nMSAoZ3R5cGUtLXJlZ2lzdGVyICcsbmFtZSAnLHBhcmVudHMgJyxhcmdz
KQogICAgIChjbC1kZWZ0eXBlICxuYW1lICxAYXJncykpKQoKKGRlZm1hY3JvIGd0eXBlLXJl
bW92ZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4g
dW5xdW90ZWQgc3ltYm9sIHJlcHJlc2VudGluZyBhIGd0eXBlLgpTaWduYWwgYW4gZXJyb3Ig
aWYgb3RoZXIgZ3R5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICBgKHByb2duCiAgICAgKGNs
LWNoZWNrLXR5cGUgJyxuYW1lIChzYXRpc2ZpZXMgZ3R5cGUtcCkpCiAgICAgKGd0eXBlLS11
bnJlZ2lzdGVyICcsbmFtZSkpKQoKOzsgSW50ZXJuYWwgZGF0YSB1c2VkIHRvIGRldGVjdCBl
bmRsZXNzIHJlY3Vyc2lvbiBpbiAnZ3R5cGUtb2YnLgooZGVmdmFyIGd0eXBlLS1vYmplY3Qg
KG1ha2Utc3ltYm9sICJ2b2lkIikpCjs7IEVhY2ggZ3R5cGUgbXVzdCBzYXRpc2ZpZXMgYGVx
bCcuCihkZWZ2YXIgZ3R5cGUtLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVh
bCkKICAiUmVjb3JkIGFuIHVuaXF1ZSB2YWx1ZSBmb3IgZWFjaCBndHlwZS4iKQoKKGRlZnVu
IGd0eXBlLW9mIChvYmplY3QpCiAgIlJldHVybiB0aGUgbW9zdCBzcGVjaWZpYyBwb3NzaWJs
ZSBndHlwZSBPQkpFQ1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5
cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMg
dHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJzaXZlIGNhbGwg
b24gdGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAgOzsgb2NjdXIg
d2hlbiwgZm9yIGV4YW1wbGUsIGEgcGFyZW50IHR5cGUgaXMgaW52ZXN0aWdhdGluZyB3aGV0
aGVyCiAgOzsgYW4gb2JqZWN0J3MgdHlwZSBpcyB0aGF0IG9mIG9uZSBvZiBpdHMgY2hpbGRy
ZW4uCiAgKHVubGVzcyAoZXEgb2JqZWN0IGd0eXBlLS1vYmplY3QpCiAgICAobGV0ICgoZ3R5
cGUtLW9iamVjdCBvYmplY3QpCiAgICAgICAgICAoZm91bmQgKGxpc3QgKGNsLXR5cGUtb2Yg
b2JqZWN0KSkpKQogICAgICA7OyBDb2xsZWN0IGFsbCBndHlwZXMgT0JKRUNUIGJlbG9uZ3Mg
dG8uCiAgICAgIChkb2xpc3QgKGd0eXBlIGd0eXBlLS1saXN0KQogICAgICAgIChpZiAoY2wt
dHlwZXAgb2JqZWN0IGd0eXBlKQogICAgICAgICAgICAocHVzaCBndHlwZSBmb3VuZCkpKQog
ICAgICA7OyBSZXR1cm4gYW4gdW5pcXVlIHZhbHVlIG9mIHR5cGUuCiAgICAgICh3aXRoLW1l
bW9pemF0aW9uIChnZXRoYXNoIGZvdW5kIGd0eXBlLS11bmlxdWUpCiAgICAgICAgZm91bmQp
KSkpCgo7OzsgTWV0aG9kIGRpc3BhdGNoaW5nCjs7CihkZWZ2YXIgZ3R5cGUtLXNwZWNpYWxp
emVycyAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcSkKICAiTWVtb2l6ZSBndHlwZSBzcGVj
aWFsaXplcnMuClRoaXMgY2FjaGUgaXMgY2xlYXJlZCBieSBgZ3R5cGUtLXJlZ2lzdGVyJyBh
bmQgYGd0eXBlLS11bnJlZ2lzdGVyJy4iKQoKKGRlZnVuIGd0eXBlLS1yZXNldC1zcGVjaWFs
aXplcnMgKG5hbWUpCiAgIlJlbW92ZSBhbGwgY2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVy
cyB3aXRoIE5BTUUuIgogIChtYXBoYXNoIChsYW1iZGEgKGtleSBfKQogICAgICAgICAgICAg
KGlmIChtZW1xIG5hbWUga2V5KQogICAgICAgICAgICAgICAgIChyZW1oYXNoIGtleSBndHlw
ZS0tc3BlY2lhbGl6ZXJzKSkpCiAgICAgICAgICAgZ3R5cGUtLXNwZWNpYWxpemVycykpCgoo
ZGVmdW4gZ3R5cGUtLXNwZWNpYWxpemVycyAodGFnICZyZXN0IF8pCiAgIklmIFRBRyBpcyBh
IGd0eXBlLCByZXR1cm4gaXRzIHNwZWNpYWxpemVycy4iCiAgOzsgVGhpcyBmdW5jdGlvbiBp
cyBvbmx5IGV2ZXIgY2FsbGVkIHdpdGggInRhZ2NvZGVzIiByZXR1cm5lZCBieQogIDs7IGBn
dHlwZS1vZicsIHNvIHRoZSBgZ3R5cGUtcCcgdGVzdCBpcyByZWR1bmRhbnQuCiAgKGFuZCAo
Y29uc3AgdGFnKSA7OyAoZ3R5cGUtcCAoY2FyIHRhZykpCiAgICAgICAod2l0aC1tZW1vaXph
dGlvbiAoZ2V0aGFzaCB0YWcgZ3R5cGUtLXNwZWNpYWxpemVycykKICAgICAgICAgKG1lcmdl
LW9yZGVyZWQtbGlzdHMgKG1hcGNhciAjJ2d0eXBlLXBhcmVudHMgdGFnKSkpKSkKCihjbC1n
ZW5lcmljLWRlZmluZS1nZW5lcmFsaXplciBndHlwZS0tZ2VuZXJhbGl6ZXIKICAyMCA7OyAi
dHlwZW9mIiBwcmlvcml0eSA8ICJndHlwZS1vZiIgcHJpb3JpdHkgPCAiaGVhZCIgcHJpb3Jp
dHkKICAobGFtYmRhIChvYmogJnJlc3QgXykgYChndHlwZS1vZiAsb2JqKSkKICAjJ2d0eXBl
LS1zcGVjaWFsaXplcnMpCgooY2wtZGVmbWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6ZXJz
IDpleHRyYSAiZ3R5cGUtb2YiICh0eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBvbiBn
dHlwZXMuIgogIChpZiAoZ3R5cGUtcCB0eXBlKQogICAgICAobGlzdCBndHlwZS0tZ2VuZXJh
bGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoKKHByb3ZpZGUgJ2d0eXBlKQoK
Ozs7IGd0eXBlLmVsIGVuZHMgaGVyZQo=
--------------VcIOq35tljgy1x8KnkSj0iEX--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 15 Apr 2025 15:14:01 +0000
Resent-Message-ID: <handler.77725.B77725.174473000910739 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174473000910739
(code B ref 77725); Tue, 15 Apr 2025 15:14:01 +0000
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 15:13:29 +0000
Received: from localhost ([127.0.0.1]:53548 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4hyZ-0002mu-G2
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:13:28 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18849)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u4hyW-0002mD-BO
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:13:25 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E10110006B;
Tue, 15 Apr 2025 11:13:18 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744729997;
bh=uYFpb0e61Wege3ORHhpLowYofkmlZ/lgu3o/74+UeEU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Mu8dF6vHa3jPsbRVctGSO9OBOXnbzJP4hE7/uRlMavWqKJIQGQfF4jxdqyTpwTwx1
o8zFooxrEaCP4tiO34f5YLvgoLwbjlFOC1nYHw0zmixFDaijV/+j0B1fAsBtvGLYjk
qKdlSHNWajmg6PQDfmEgpq7k5ya2LruxTVGqHstOtzlgeQngf0Yf2r/TM9tcRIVeoF
qF3XhzqJa+ftSFxZBQjg8dpy5GhtWBoEmElGVEy9hJ15cu3N55UrBHlWMZOfmRSgij
kJ6T27bpyyHfkh2+F6yMayYxyDEXQph6NKBFtkC0A4Kj/JC51A0Rcjq8x2st7ZRiY3
zzyY6Tfd+j0WQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4E54F100027;
Tue, 15 Apr 2025 11:13:17 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27F24120323;
Tue, 15 Apr 2025 11:13:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
Message-ID: <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
Date: Tue, 15 Apr 2025 11:13:16 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.378 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> (eval-when-compile (require 'cl-macs)) ;For cl--find-class.
>> You can also use `cl-find-class` which doesn't require this gymnastics.
>
> Done. I didn't know about this public version of `cl--find-class'.
> However, as it seems not possible to write:
>
> `(setf (cl-find-class object) value)'
Ah, right, we still don't have a pubic version of defining a class,
indeed, sorry. I guess `cl--find-class` it is, huh.
>> I get the impression that the role/impact of PARENTS is not explained
>> clearly enough. The explanation should be clear enough that the reader
>> can infer more or less what could happen if a parent is missing or if
>> a non-parent is incorrectly listed as a parent.
> This is a very good point. Currently, the role of PARENTS is limited
> to specify in which order gtype `gtype-of' will check gtypes.
Why does this order matter? I thought the PARENTS was used just in
`gtype--specializers` to sort the various types.
> For instance, you can do something like this:
>
> (defgtype a-fixnum nil ()
> 'fixnum)
>
> (gtype-of 10)
> (a-fixnum fixnum)
>
> (defgtype a-fixnum-between-1-10 a-fixnum ()
> `(satisfies ,(lambda (x) (and (numberp x) (> x 0) (< x 11)))))
>
> (gtype-of 10.1)
> (a-fixnum-between-1-10 float)
> gtype--list
> (a-fixnum-between-1-10 a-fixnum)
>
> Clearly 10.1 is not "a-fixnum-between-1-10", because the type
> specifier is incorrect; even if `a-fixnum-between-1-10' is a subtype
> of `a-fixnum'.
>
> The correct subtype could be:
>
> (defgtype a-fixnum-between-1-10 a-fixnum ()
> `(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
>
> But the type specifier is not produced automatically.
AFAICT the error will manifest itself in the fact that
`gtype--specializers` will return
(a-fixnum-between-1-10 a-fixnum float fixnum integer ...)
so a method defined `a-fixnum` may end up incorrectly invoked in this case.
In contrast if `a-fixnum` is missing:
(defgtype a-fixnum-between-1-10 nil ()
`(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
then `gtype--specializers` may end up returning
(a-fixnum a-fixnum-between-1-10 float fixnum integer ...)
so a method defined for `a-fixnum` may take precedence over one defined
for `a-fixnum-between-1-10`.
> Not so easy to put all this in a docstring. Any idea?
AFAICT, missing PARENTS may cause incorrect ordering of methods,
while extraneous PARENTS may cause use of extraneous methods.
>>> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
>>> (cl-with-gensyms (err)
>>> `(condition-case ,err
>>> (progn
>>> (cl-deftype ,name ,@args)
>>> (gtype--register ',name ',parents ',args))
>>> (error
>>> (gtype--unregister ',name)
>>> (error (error-message-string ,err))))))
>> Could we merge this into `cl-deftype`?
>
> That would be great. But I need some help here to correctly dispatch
> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
`cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
> May be in this case, gtype should be moved to the cl namespace too.
Yup. I guess they'd become "cl-types" instead of "gtypes".
> Or do you envision something different?
I was thinking that the main(only?) difference between `cl-deftype` and
`gdeftype` is:
- the PARENTS argument, where the question is how to add a PARENTS
argument. Maybe we could use a (declare (parents ...))?
- The ARGS: Clearly your `gtype-of` can invent which args to pass
for a given value to match the resulting type, so `gtype-of` (and
everything which relies on it, i.e. method dispatch) wouldn't be
usable for types with a non-empty arglist.
>> But the above looks rather costly. =F0=9F=99=81
>
> emacs -Q on my laptop:
>
> Processors: 8 =C3=97 Intel=C2=AE Core=E2=84=A2 i7-7700HQ CPU @ 2.80GHz
> Memory: 15,5 GiB of RAM
>
> consistently takes around 1 millisecond to check 2000 gtypes, which
> seems not so bad.
AFAICT its CPU cost is proportional to the number of types defined with
`defgtype`, so the more popular it gets, the slower it becomes.
And of course, the cost of each type check is unbounded, so a single
"expensive" type can slow everything down further.
The usual dispatch is
(lambda (arg &rest args)
(let ((f (gethash (cl-typeof arg) precomputed-methods-table)))
(if f
(apply f arg args)
;; Slow case when encountering a new type
...)))
where often the most expensive part is `&rest` (which has to allocate
a list for those remaining arguments),
So we're talking about replacing
&rest + cl-type-of + gethash + if + apply
with a function that loops over N types, calling `cl-typep` on each one
of them (`cl-typep` itself being a recursive function that basically
interprets the type language). This is going to slow down dispatch
*very* significantly for those generic functions that have a method that
dispatches on a gtype, compared to those that don't.
It's not the end of the world, especially because there's a lot of
opportunities for optimizations in there, but it's something to keep
in mind.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 15 Apr 2025 16:41:04 +0000
Resent-Message-ID: <handler.77725.B77725.174473525925965 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174473525925965
(code B ref 77725); Tue, 15 Apr 2025 16:41:04 +0000
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 16:40:59 +0000
Received: from localhost ([127.0.0.1]:54483 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4jLE-0006kO-Uz
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 12:40:59 -0400
Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:37283
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u4jLA-0006jB-7h
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 12:40:54 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 4jL3ubMfUOaHY4jL6ullYy; Tue, 15 Apr 2025 18:40:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744735250;
bh=KTFgPY1OrHLiC8agUTqeR/+FdUF03jrinXGOHLOw3Hc=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=HjjnjfohDSTldUv6t42b1mtxfdVsnXnoog7dQedNxG1WP3buZvMw63DYifgdSwgTW
ebbRyyvftlmzsjXS/zZWvJUfdAPd7e9YUbczJRUn2fnqxdqTKQ8a5ya53HP1TgT0LI
qdyB9L9NeGGdQBuQxRDQosSiDiwLSqWU5hZ+trD1m2FMi94AzJagT+evsIcaS4/Ion
q3IFzAwAWhLcroIpEAEMvyNbdxs27eBBdN4z2XsUGZp+SYtvY9n5BFW/+piASSjfsy
zPcoMK/oio9UC53wYaSktXvA0TGyu9cWMY2yANL9TIM3qx+4XDcoPkgC0eeIq9B/wD
bqskTTnskSOSg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Tue, 15 Apr 2025 18:40:50 +0200
X-ME-IP: 90.112.40.65
Message-ID: <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
Date: Tue, 15 Apr 2025 18:40:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-15 17:13, Stefan Monnier wrote:
>>> I get the impression that the role/impact of PARENTS is not explained
>>> clearly enough. The explanation should be clear enough that the reader
>>> can infer more or less what could happen if a parent is missing or if
>>> a non-parent is incorrectly listed as a parent.
>> This is a very good point. Currently, the role of PARENTS is limited
>> to specify in which order gtype `gtype-of' will check gtypes.
>
> Why does this order matter? I thought the PARENTS was used just in
> `gtype--specializers` to sort the various types.
Sorry for the confusion, you are right, of course.
>> For instance, you can do something like this:
>>
>> (defgtype a-fixnum nil ()
>> 'fixnum)
>>
>> (gtype-of 10)
>> (a-fixnum fixnum)
>>
>> (defgtype a-fixnum-between-1-10 a-fixnum ()
>> `(satisfies ,(lambda (x) (and (numberp x) (> x 0) (< x 11)))))
>>
>> (gtype-of 10.1)
>> (a-fixnum-between-1-10 float)
>> gtype--list
>> (a-fixnum-between-1-10 a-fixnum)
>>
>> Clearly 10.1 is not "a-fixnum-between-1-10", because the type
>> specifier is incorrect; even if `a-fixnum-between-1-10' is a subtype
>> of `a-fixnum'.
>>
>> The correct subtype could be:
>>
>> (defgtype a-fixnum-between-1-10 a-fixnum ()
>> `(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
>>
>> But the type specifier is not produced automatically.
>
> AFAICT the error will manifest itself in the fact that
> `gtype--specializers` will return
>
> (a-fixnum-between-1-10 a-fixnum float fixnum integer ...)
>
> so a method defined `a-fixnum` may end up incorrectly invoked in this case.
>
> In contrast if `a-fixnum` is missing:
>
> (defgtype a-fixnum-between-1-10 nil ()
> `(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
>
> then `gtype--specializers` may end up returning
>
> (a-fixnum a-fixnum-between-1-10 float fixnum integer ...)
>
> so a method defined for `a-fixnum` may take precedence over one defined
> for `a-fixnum-between-1-10`.
>
>> Not so easy to put all this in a docstring. Any idea?
>
> AFAICT, missing PARENTS may cause incorrect ordering of methods,
> while extraneous PARENTS may cause use of extraneous methods.
I will add this to the docstring.
>
>>>> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
>>>> (cl-with-gensyms (err)
>>>> `(condition-case ,err
>>>> (progn
>>>> (cl-deftype ,name ,@args)
>>>> (gtype--register ',name ',parents ',args))
>>>> (error
>>>> (gtype--unregister ',name)
>>>> (error (error-message-string ,err))))))
>>> Could we merge this into `cl-deftype`?
>>
>> That would be great. But I need some help here to correctly dispatch
>> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
>
> Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
> `cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
Shouldn't the code related to method dispatching, at the end of gtype.el,
go to cl-generic?
>> May be in this case, gtype should be moved to the cl namespace too.
>
> Yup. I guess they'd become "cl-types" instead of "gtypes".
>
>> Or do you envision something different?
>
> I was thinking that the main(only?) difference between `cl-deftype` and
> `gdeftype` is:
>
> - the PARENTS argument, where the question is how to add a PARENTS
> argument. Maybe we could use a (declare (parents ...))?
Another possibility could be to have 2 separate definitions:
- cl-deftype to define a data type, as currently.
- cl-types-generalize (or something better) to declare a type previously
defined by cl-deftype usable to dispatch methods, with specified parents?
(cl-deftype my-type ()
"A user defined type."
...)
(cl-types-generalize my-type) ;; No parents
(cl-deftype my-type1 ()
"Another user defined type."
...)
(cl-types-generalize my-type1 my-type) ;; With parents
It should be possible also to "un-generalize" a type.
> - The ARGS: Clearly your `gtype-of` can invent which args to pass
> for a given value to match the resulting type, so `gtype-of` (and
> everything which relies on it, i.e. method dispatch) wouldn't be
> usable for types with a non-empty arglist.
I am not sure I understand this point regarding ARGS.
Is this related to the `cl-deftype' arguments which cannot be used to
declare argument type of methods:
(defgtype unsigned-byte nil (&optional bits)
(list 'integer 0 (if (eq bits '*) bits (1- (ash 1 bits)))))
(cl-defmethod my-foo ((n (unsigned-byte 8))) ;; fails
(format "unsigned, %s" n))
But, below is possible instead:
(defgtype u8 unsigned-byte ()
'(unsigned-byte 8))
(cl-defmethod my-foo ((n u8))
(format "unsigned 8bits, %s - also %s"
n (cl-call-next-method)))
(my-foo 100)
=> "unsigned 8bits, 100 - also unsigned, 100"
(my-foo 256)
=> "unsigned, 256"
>
>>> But the above looks rather costly. 🙁
>>
>> emacs -Q on my laptop:
>>
>> Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
>> Memory: 15,5 GiB of RAM
>>
>> consistently takes around 1 millisecond to check 2000 gtypes, which
>> seems not so bad.
>
> AFAICT its CPU cost is proportional to the number of types defined with
> `defgtype`, so the more popular it gets, the slower it becomes.
> And of course, the cost of each type check is unbounded, so a single
> "expensive" type can slow everything down further.
>
> The usual dispatch is
>
> (lambda (arg &rest args)
> (let ((f (gethash (cl-typeof arg) precomputed-methods-table)))
> (if f
> (apply f arg args)
> ;; Slow case when encountering a new type
> ...)))
>
> where often the most expensive part is `&rest` (which has to allocate
> a list for those remaining arguments),
>
> So we're talking about replacing
>
> &rest + cl-type-of + gethash + if + apply
>
> with a function that loops over N types, calling `cl-typep` on each one
> of them (`cl-typep` itself being a recursive function that basically
> interprets the type language). This is going to slow down dispatch
> *very* significantly for those generic functions that have a method that
> dispatches on a gtype, compared to those that don't.
>
> It's not the end of the world, especially because there's a lot of
> opportunities for optimizations in there, but it's something to keep
> in mind.
Sure.
Thanks you again.
David
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 15 Apr 2025 19:18:02 +0000
Resent-Message-ID: <handler.77725.B77725.174474465216733 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174474465216733
(code B ref 77725); Tue, 15 Apr 2025 19:18:02 +0000
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 19:17:32 +0000
Received: from localhost ([127.0.0.1]:55653 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4lml-0004Lp-I1
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 15:17:31 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60157)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u4lmi-0004LU-Os
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 15:17:29 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7ED2C10006B;
Tue, 15 Apr 2025 15:17:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744744639;
bh=x4h689TxI62nU9kpKuowSLhSsHhT5I12+dDluphJuIk=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Tv6tKk4yJr+Z59c8GMv5qE867RJM1Yxe44jvG65tuHypoxXj+d7AFScqDWUjwsoSJ
QzwzQoXAgQydWFRGLRltwqM8KE2z1P9XAalnGPYFXvs6QVcnNi6Evt7nY0fYox+etd
BRLwfTy2RtHO5+PXHF801F9E3Xw4q0kUMtCekOW3qAdSoQpD6Mk5+IHqirvqtCquO2
AHkte45LAGsTUhUvM2QbBY0+rabjEj8/eFH5pVQuMFW6pQPk/2ZDYWEltcWYbRV0ES
ZOeOyD0V+HxeGWwJrSi1qsRfuSz7xO7Y7kUZ8Vn1yhpkmYWdrrRW/kYFGKgkp6lJQv
WCsIWPwmWrtWg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B635F100027;
Tue, 15 Apr 2025 15:17:19 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B9A31202D5;
Tue, 15 Apr 2025 15:17:19 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
Message-ID: <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
Date: Tue, 15 Apr 2025 15:17:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.376 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> That would be great. But I need some help here to correctly dispatch
>>> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
>> Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
>> `cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
> Shouldn't the code related to method dispatching, at the end of gtype.el,
> go to cl-generic?
Technically it can go to various places, but ideally `cl-generic` just
provides the machinery whereas the actual generalizers would be
defined next to where we define the corresponding types. In practice,
we have most of the `cl-generic-define-generalizer` in there,
admittedly, but that's because of overriding bootstrapping issues.
Since we're talking about generalizers defined for `cl-deftype` which is
not a core primitive but one defined in `cl-lib`, it makes sense to
define it elsewhere (i.e. in the `cl-lib` files), like we do for
EIEIO types.
>> I was thinking that the main(only?) difference between `cl-deftype` and
>> `gdeftype` is:
>> - the PARENTS argument, where the question is how to add a PARENTS
>> argument. Maybe we could use a (declare (parents ...))?
>
> Another possibility could be to have 2 separate definitions:
>
> - cl-deftype to define a data type, as currently.
>
> - cl-types-generalize (or something better) to declare a type previously
> defined by cl-deftype usable to dispatch methods, with specified parents?
>
> (cl-deftype my-type ()
> "A user defined type."
> ...)
> (cl-types-generalize my-type) ;; No parents
>
> (cl-deftype my-type1 ()
> "Another user defined type."
> ...)
> (cl-types-generalize my-type1 my-type) ;; With parents
We could, but having them separate begs the question of how to match one
with the other: e.g. if we re-evaluate (cl-deftype my-type ...) should the
corresponding previous (cl-types-generalize ...) be "undone"?
It's somewhat philosophical, admittedly, but bringing them together
makes it much more clear what is the "right" behavior (regardless if we
end up implementing the right behavior: at least when we get
a bug-report, we know which change is an improvement).
>> - The ARGS: Clearly your `gtype-of` can invent which args to pass
>> for a given value to match the resulting type, so `gtype-of` (and
>> everything which relies on it, i.e. method dispatch) wouldn't be
>> usable for types with a non-empty arglist.
>
> I am not sure I understand this point regarding ARGS.
> Is this related to the `cl-deftype' arguments which cannot be used to
> declare argument type of methods:
Exactly. `cl-deftype` lets you define types such as `(list-of
integer)`, but your code is not able to figure out that a value is of
type `(list-of integer)` so you can't handle those kinds of types.
And that's OK: it's still better than what we currently have.
> But, below is possible instead:
>
> (defgtype u8 unsigned-byte ()
> '(unsigned-byte 8))
>
> (cl-defmethod my-foo ((n u8))
> (format "unsigned 8bits, %s - also %s"
> n (cl-call-next-method)))
That's right.
We could try to later add support for
(cl-defmethod my-foo ((n (unsigned-byte 8)))
(format "unsigned, %s" n))
but ... one step at a time.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 16 Apr 2025 15:18:04 +0000
Resent-Message-ID: <handler.77725.B77725.174481667028127 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174481667028127
(code B ref 77725); Wed, 16 Apr 2025 15:18:04 +0000
Received: (at 77725) by debbugs.gnu.org; 16 Apr 2025 15:17:50 +0000
Received: from localhost ([127.0.0.1]:40364 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u54WK-0007JV-Vk
for submit <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:17:50 -0400
Received: from smtp-30.smtpout.orange.fr ([80.12.242.30]:55669
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u54WG-0007JE-G9
for 77725 <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:17:46 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 54W8ubdic1J2g54WCuvErr; Wed, 16 Apr 2025 17:17:42 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744816662;
bh=WlTVe8zAXPdY1jBrOe+EKQmT3vu2i7wM7PfLBCLYlM8=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=HM2AEIxiHj8GfV4KL+S3Qcj0YNgHxp75hxTxuXNbHLkRzPB6l/izrvu0ZyjQISsn0
YI8LzCU3lH3KWDu2GKyD6xw++Ld7rEMlELdI2lMi/b/jEEHS0CX9u9RVjypH0OHXls
8MkGEMiCl4uo+aUOl7cb+jH7B56UlY2U3c3S/caY1+DAKGVDBN5lNGIEap4kj0BKAx
+HlJ/Vt4m6MF9a/NxITL8yvWiy00vfays340/PrSADDEneOdB24bFAPD1I0witVCZr
HBnscAlJHB1UZdIEnEc5TJ03AFFHCQT64Wh1q7sT5m8Cj/wIzvwteHDZqBj43ze7+z
uUzUwxYpMvkVA==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Wed, 16 Apr 2025 17:17:42 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------NmUF7puYso0yKcC0qzFBhzuT"
Message-ID: <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Date: Wed, 16 Apr 2025 17:17:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------NmUF7puYso0yKcC0qzFBhzuT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2025-04-15 21:17, Stefan Monnier wrote:
>>>> That would be great. But I need some help here to correctly dispatch
>>>> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
>>> Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
>>> `cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
>> Shouldn't the code related to method dispatching, at the end of gtype.el,
>> go to cl-generic?
>
> Technically it can go to various places, but ideally `cl-generic` just
> provides the machinery whereas the actual generalizers would be
> defined next to where we define the corresponding types. In practice,
> we have most of the `cl-generic-define-generalizer` in there,
> admittedly, but that's because of overriding bootstrapping issues.
>
> Since we're talking about generalizers defined for `cl-deftype` which is
> not a core primitive but one defined in `cl-lib`, it makes sense to
> define it elsewhere (i.e. in the `cl-lib` files), like we do for
> EIEIO types.
OK.
>
>>> I was thinking that the main(only?) difference between `cl-deftype` and
>>> `gdeftype` is:
>>> - the PARENTS argument, where the question is how to add a PARENTS
>>> argument. Maybe we could use a (declare (parents ...))?
>>
>> Another possibility could be to have 2 separate definitions:
>>
>> - cl-deftype to define a data type, as currently.
>>
>> - cl-types-generalize (or something better) to declare a type previously
>> defined by cl-deftype usable to dispatch methods, with specified parents?
>>
>> (cl-deftype my-type ()
>> "A user defined type."
>> ...)
>> (cl-types-generalize my-type) ;; No parents
>>
>> (cl-deftype my-type1 ()
>> "Another user defined type."
>> ...)
>> (cl-types-generalize my-type1 my-type) ;; With parents
>
> We could, but having them separate begs the question of how to match one
> with the other: e.g. if we re-evaluate (cl-deftype my-type ...) should the
> corresponding previous (cl-types-generalize ...) be "undone"?
>
> It's somewhat philosophical, admittedly, but bringing them together
> makes it much more clear what is the "right" behavior (regardless if we
> end up implementing the right behavior: at least when we get
> a bug-report, we know which change is an improvement).
I agree.
>
>>> - The ARGS: Clearly your `gtype-of` can invent which args to pass
>>> for a given value to match the resulting type, so `gtype-of` (and
>>> everything which relies on it, i.e. method dispatch) wouldn't be
>>> usable for types with a non-empty arglist.
>>
>> I am not sure I understand this point regarding ARGS.
>> Is this related to the `cl-deftype' arguments which cannot be used to
>> declare argument type of methods:
>
> Exactly. `cl-deftype` lets you define types such as `(list-of
> integer)`, but your code is not able to figure out that a value is of
> type `(list-of integer)` so you can't handle those kinds of types.
> And that's OK: it's still better than what we currently have.
>
>> But, below is possible instead:
>>
>> (defgtype u8 unsigned-byte ()
>> '(unsigned-byte 8))
>>
>> (cl-defmethod my-foo ((n u8))
>> (format "unsigned 8bits, %s - also %s"
>> n (cl-call-next-method)))
>
> That's right.
OK.
>
> We could try to later add support for
>
> (cl-defmethod my-foo ((n (unsigned-byte 8)))
> (format "unsigned, %s" n))
>
> but ... one step at a time.
Sure. Even better could be to support the full type-specifier syntax
;-)
Please find attached a first attempt at a cl-types.el to be merged in
cl-lib. Please feel free to propose new names if mine are not good.
For now, the new `cl-deftype' is named `cl-deftype2' for testing
without impacting the existing environment.
I tried to consistent at using the `cl-type-' prefix (or `cl--type-'
for internals). But some names are very close to already existing
ones, like 'cl-type-p' vs. `cl-typep'. There is also a collision with
the name `cl-type-of', already used for a builtin function, so I used
the name `cl-types-of' which also better represent that this function
returns a list of types.
The new code is also better at handling errors. It should detect most
of the possible errors, and will restore the current environnement on
error. I also tried to improve cl-types-of. Please read my comments
in the code.
WDYT?
Thanks!
David
--------------NmUF7puYso0yKcC0qzFBhzuT
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl
biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCgooZGVjbGFyZS1mdW5j
dGlvbiBjbC1maW5kLWNsYXNzICJjbC1leHRyYSIgKHR5cGUpKQooZGVjbGFyZS1mdW5jdGlv
biBjbC1yZW1wcm9wICJjbC1leHRyYSIgKHN5bWJvbCBwcm9wbmFtZSkpCgo7OyBFeHRlbmQg
YGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdoaWNoIGFyZSBhbHNvIHZhbGlk
Cjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBnZW5lcmljIGZ1bmN0aW9uIG1l
dGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3MuZ251Lm9yZy9jZ2kvYnVncmVw
b3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToK
OzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBuZXcgZGF0YSB0eXBlcy4KOzsK
OzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IGxvb2t1cHMgdGhlIHR5cGVzIGFuIG9iamVjdCBi
ZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5pbAogICJMaXN0IG9mIGRlZmlu
ZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuIikKCihkZWZ1biBj
bC10eXBlLXAgKG9iamVjdCkKICAiUmV0dXJuIG5vbi1uaWwgaWYgT0JKRUNUIGlzIGEgdXNl
ZCBkZWZpbmVkIHR5cGUuClRoYXQgaXMsIGEgdHlwZSBvZiBjbGFzcyBgY2wtdHlwZS1jbGFz
cycuIgogIChhbmQgKHN5bWJvbHAgb2JqZWN0KQogICAgICAgKGVxICh0eXBlLW9mIChjbC1m
aW5kLWNsYXNzIG9iamVjdCkpICdjbC10eXBlLWNsYXNzKSkpCgooY2wtZGVmc3RydWN0CiAg
ICAoY2wtdHlwZS1jbGFzcwogICAgICg6aW5jbHVkZSBjbC0tY2xhc3MpCiAgICAgKDpub2lu
bGluZSB0KQogICAgICg6Y29uc3RydWN0b3IgbmlsKQogICAgICg6Y29uc3RydWN0b3IgY2wt
LXR5cGUtY2xhc3MtbWFrZQogICAgICAgICAgICAgICAgICAgKG5hbWUKICAgICAgICAgICAg
ICAgICAgICBkb2NzdHJpbmcKICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMKICAg
ICAgICAgICAgICAgICAgICAmYXV4IChwYXJlbnRzCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgKG1hcGNhcgogICAgICAgICAgICAgICAgICAgICAgICAgICAobGFtYmRhICh0eXBlKQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC1jaGVjay10eXBlIHR5cGUgKHNhdGlz
ZmllcyBjbC10eXBlLXApKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC1maW5k
LWNsYXNzIHR5cGUpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMp
KSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3IgdXNlciBk
ZWZpbmVkIHR5cGVzLiIpCgooZGVmdW4gY2wtdHlwZS1wYXJlbnRzIChuYW1lKQogICJHZXQg
cGFyZW50cyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCByZXByZXNlbnRp
bmcgYSB0eXBlLiIKICAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLWZpbmQtY2xhc3MgbmFt
ZSkpKQoKKGRlZnVuIGNsLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGlsZHJlbiBv
ZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEg
dHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNsLWNo
ZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLXR5cGUtcCkpCiAgKGxldCAoY2hpbGRyZW4p
CiAgICAoZG9saXN0IChlbHQgY2wtLXR5cGUtbGlzdCkKICAgICAgKG9yIChlcSBuYW1lIGVs
dCkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIChjbC10eXBlLXBhcmVudHMgZWx0KSkKICAg
ICAgICAgICAgICAocHVzaCBlbHQgY2hpbGRyZW4pKSkpCiAgICBjaGlsZHJlbikpCgooZGVm
dW4gY2wtLXR5cGUtZGFnICgpCiAgIlJldHVybiBhIERBRyBmcm9tIHRoZSBsaXN0IG9mIGRl
ZmluZWQgdHlwZXMuIgogIChjbC1sYWJlbHMgKChhbGxwYXJlbnRzIChjbGFzcykKICAgICAg
ICAgICAgICAgIChsZXQgKCh0eXBlIChjbC0tY2xhc3MtbmFtZSBjbGFzcykpKQogICAgICAg
ICAgICAgICAgICA7OyBFeGNsdWRlIG5vbi1jbC10eXBlLXAgZnJvbSB0aGUgREFHLgogICAg
ICAgICAgICAgICAgICAoaWYgKGNsLXR5cGUtcCB0eXBlKQogICAgICAgICAgICAgICAgICAg
ICAgKGNvbnMgdHlwZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1lcmdlLW9yZGVy
ZWQtbGlzdHMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyICMnYWxscGFy
ZW50cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNsLS1jbGFzcy1w
YXJlbnRzIGNsYXNzKSkpKSkpKSkKICAgIChtYXBjYXIgKGxhbWJkYSAodHlwZSkgKGFsbHBh
cmVudHMgKGNsLWZpbmQtY2xhc3MgdHlwZSkpKQogICAgICAgICAgICBjbC0tdHlwZS1saXN0
KSkpCgooZGVmdW4gY2wtLXR5cGUtdW5kZWZpbmUgKG5hbWUpCiAgIlJlbW92ZSB0aGUgZGVm
aW5pdGlvbiBvZiB0eXBlIHdpdGggTkFNRS4iCiAgKHdoZW4tbGV0KiAoKGNoaWxkcmVuIChh
bmQgKGNsLXR5cGUtcCBuYW1lKSAoY2wtdHlwZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVy
cm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMiIGNoaWxkcmVuKSkKICA7OyBDbGVhciBjYWNo
ZWQgdmFsdWUgb2Ygc3BlY2lhbGl6ZXJzIHdpdGggTkFNRS4KICAoY2wtLXR5cGUtcmVzZXQt
c3BlY2lhbGl6ZXJzIG5hbWUpCiAgKGNsLXJlbXByb3AgbmFtZSAnY2wtLWNsYXNzKQogIChj
bC1yZW1wcm9wIG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcikKICAoc2V0cSBjbC0tdHlwZS1s
aXN0IChkZWxxIG5hbWUgY2wtLXR5cGUtbGlzdCkpKQoKKGRlZnVuIGNsLS10eXBlLWdlbmVy
YWxpemUgKG5hbWUgYXJnbGlzdCBib2R5KQogICJHZW5lcmFsaXplIHR5cGUgd2l0aCBOQU1F
IGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuCkFSR0xJU1QgYW5kIEJPRFkgYXJlIHBhc3NlZCB0
byBgY2wtZGVmdHlwZScuIgogIChsZXQgKChvbGR0bGlzdCAoY29weS1zZXF1ZW5jZSBjbC0t
dHlwZS1saXN0KSkKCShvbGRwbGlzdCAoY29weS1zZXF1ZW5jZSAoc3ltYm9sLXBsaXN0IG5h
bWUpKSkpCiAgICAoY29uZGl0aW9uLWNhc2UgZXJyCiAgICAgICAgKHBjYXNlLWxldCogKChg
KCxkZWNscyAuICxib2R5KSAobWFjcm9leHAtcGFyc2UtYm9keSBib2R5KSkKICAgICAgICAg
ICAgICAgICAgICAgKGRvY3N0cmluZyAoaWYgKHN0cmluZ3AgKGNhciBkZWNscykpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwb3AgZGVjbHMpCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3NxIDpkb2N1bWVudGF0aW9uIGRlY2xz
KSkpKQogICAgICAgICAgICAgICAgICAgICAoZGVjbHMgICAoY2RyIChhc3NxICdkZWNsYXJl
IGRlY2xzKSkpCiAgICAgICAgICAgICAgICAgICAgIChwYXJlbnRzIChjZHIgKGFzc3EgJ3N1
YnR5cGUtb2YgZGVjbHMpKSkKICAgICAgICAgICAgICAgICAgICAgKGNsYXNzICAgKGNsLWZp
bmQtY2xhc3MgbmFtZSkpCiAgICAgICAgICAgICAgICAgICAgIChyZWdlZCAgIChtZW1xIG5h
bWUgY2wtLXR5cGUtbGlzdCkpKQogICAgICAgICAgKGlmIChudWxsIGNsYXNzKQogICAgICAg
ICAgICAgIChvciAobnVsbCByZWdlZCkKICAgICAgICAgICAgICAgICAgKGVycm9yICJUeXBl
IGdlbmVyYWxpemVkLCBidXQgZG9lc24ndCBleGlzdCIpKQogICAgICAgICAgICAob3IgcmVn
ZWQgIlR5cGUgZXhpc3RzLCBidXQgbm90IGdlbmVyYWxpemVkIikKICAgICAgICAgICAgKG9y
IChlcSAodHlwZS1vZiBjbGFzcykgJ2NsLXR5cGUtY2xhc3MpCiAgICAgICAgICAgICAgICAo
ZXJyb3IgIlR5cGUgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNsYXNzKSkpKQog
ICAgICAgICAgKG9yIChsaXN0cCBwYXJlbnRzKSAoc2V0cSBwYXJlbnRzIChsaXN0IHBhcmVu
dHMpKSkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgICAgICAg
KGVycm9yICJUeXBlIGluIHBhcmVudHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICAgIDs7IFNl
dHVwIGEgdHlwZSBkZXNjcmlwdG9yIGZvciBOQU1FLiAgQ2FuJ3QgdXNlIGBzZXRmJyB3aXRo
CiAgICAgICAgICA7OyBgY2wtZmluZC1jbGFzcycsIHNvIGZhbGxiYWNrIHRvIHBsYWluIGBw
dXQnIHRvIHNldCB0aGUKICAgICAgICAgIDs7IGBjbC0tY2xhc3MnIHN5bWJvbCBwcm9wZXJ0
eS4KICAgICAgICAgIChwdXQgbmFtZSAnY2wtLWNsYXNzCiAgICAgICAgICAgICAgIChjbC0t
dHlwZS1jbGFzcy1tYWtlIG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKQogICAgICAgICAgOzsg
Q2xlYXIgY2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVycyB3aXRoIE5BTUUuCiAgICAgICAg
ICAoaWYgY2xhc3MKCSAgICAgIChjbC0tdHlwZS1yZXNldC1zcGVjaWFsaXplcnMgbmFtZSkK
CSAgICA7OyBSZWNvcmQgbmV3IHR5cGUuCgkgICAgKHB1c2ggbmFtZSBjbC0tdHlwZS1saXN0
KSkKICAgICAgICAgIDs7IEtlZXAgbW9zdCBzcGVjaWZpYyB0eXBlcyBiZWZvcmUgbW9yZSBn
ZW5lcmFsIHR5cGVzLgogICAgICAgICAgKHNldHEgY2wtLXR5cGUtbGlzdCAobWVyZ2Utb3Jk
ZXJlZC1saXN0cwoJCQkgICAgICAgKGNsLS10eXBlLWRhZykKCQkJICAgICAgIChsYW1iZGEg
KGcpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiSW52YWxpZCBE
QUcsICVTIiBnKSkpKQogICAgICAgICAgOzsgUmV0dXJuIHRoZSBmb3JtIHRvIGRlY2xhcmUg
dGhlIHR5cGUuCiAgICAgICAgICBgKGNsLWV2YWwtd2hlbiAoY29tcGlsZSBsb2FkIGV2YWwp
CiAgICAgICAgICAgICAoZGVmaW5lLXN5bWJvbC1wcm9wICcsbmFtZSAnY2wtZGVmdHlwZS1o
YW5kbGVyCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC1mdW5jdGlvbgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAoJmNsLWRlZnMgKCcq
KSAsQGFyZ2xpc3QpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICxkb2Nz
dHJpbmcKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLEBib2R5KSkpKSkK
ICAgICAgKGVycm9yCiAgICAgICA7OyBPbiBlcnJvciByZXN0b3JlIHRoZSBwcmV2aW91cyBk
YXRhLgogICAgICAgKHNldHEgY2wtLXR5cGUtbGlzdCBvbGR0bGlzdCkKICAgICAgIChzZXRm
IChzeW1ib2wtcGxpc3QgbmFtZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAi
RGVmaW5lICVTIGZhaWxlZDogJXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJv
ci1tZXNzYWdlLXN0cmluZyBlcnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8g
Y2wtZGVmdHlwZTIgKG5hbWUgYXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBh
cyBhIG5ldyBkYXRhIHR5cGUuClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBg
Y2wtdHlwZWNhc2UnLCBgY2wtY2hlY2stdHlwZScsIGV0YywKYW5kIGFzIGFyZ3VtZW50IHR5
cGUgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KCkFSR0xJU1Qg
aXMgYSBDb21tb24gTGlzcCBhcmd1bWVudCBsaXN0IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5
CmBjbC1kZWZtYWNybycuICBCT0RZIGZvcm1zIGFyZSBldmFsdWF0ZWQgYW5kIHNob3VsZCBy
ZXR1cm4gYSB0eXBlCnNwZWNpZmllciB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUg
KHNlZSB0aGUgSW5mbyBub2RlIGAoY2wpIFR5cGUKUHJlZGljYXRlcycgaW4gdGhlIEdOVSBF
bWFjcyBDb21tb24gTGlzcCBFbXVsYXRpb24gbWFudWFsKS4KCklmIHRoZSBmaXJzdCBmb3Jt
IGluIEJPRFkgaXMgYSBgZGVjbGFyZScgZm9ybSwgdGhlIHNwZWMgKHN1YnR5cGUtb2YKUEFS
RU5UUykgaXMgcmVjb2duaXplZCB0byBzcGVjaWZ5IGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlz
IGEgc3VidHlwZQpvZi4gIEZvciBpbnN0YW5jZToKCiAgKGNsLWRlZnR5cGUyIHVuc2lnbmVk
LWJ5dGUgKCZvcHRpb25hbCBiaXRzKQogICAgXCJVbnNpZ25lZCBpbnRlZ2VyLlwiCiAgICAo
bGlzdCBcXD0naW50ZWdlciAwIChpZiAoZXEgYml0cyBcXD0nKikgYml0cyAoMS0gKGFzaCAx
IGJpdHMpKSkpKQoKICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgIFwiVW5z
aWduZWQgOC1iaXRzIGludGVnZXIuXCIKICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVuc2ln
bmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNpZ25lZC1ieXRlIDgpKQoKVGhlIGxpc3Qgb2YgUEFS
RU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRoZSBvcmRlciBvZiBtZXRob2RzIGludm9jYXRpb24s
CmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5IGNhdXNlIGluY29ycmVjdCBvcmRlcmluZyBvZiBt
ZXRob2RzLCB3aGlsZQpleHRyYW5lb3VzIFBBUkVOVFMgbWF5IGNhdXNlIHVzZSBvZiBleHRy
YW5lb3VzIG1ldGhvZHMuIgogIChkZWNsYXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1z
dHJpbmcgMykgKGluZGVudCAyKSkKICAoY2wtLXR5cGUtZ2VuZXJhbGl6ZSBuYW1lIGFyZ2xp
c3QgYm9keSkpCgooZGVmbWFjcm8gY2wtdHlwZS11bmRlZmluZSAobmFtZSkKICAiUmVtb3Zl
IHRoZSBkZWZpbml0aW9ucyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1bnF1b3Rl
ZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlwZS4KU2lnbmFsIGFuIGVycm9yIGlmIG90aGVy
IHR5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICBgKHByb2duCiAgICAgKGNsLWNoZWNrLXR5
cGUgJyxuYW1lIChzYXRpc2ZpZXMgY2wtdHlwZS1wKSkKICAgICAoY2wtLXR5cGUtdW5kZWZp
bmUgJyxuYW1lKSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3Mg
cmVjdXJzaW9uIGluICdjbC10eXBlLW9mJy4KKGRlZnZhciBjbC0tdHlwZS1vYmplY3QgKG1h
a2Utc3ltYm9sICJ2b2lkIikpCjs7IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwn
LgooZGVmdmFyIGNsLS10eXBlLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVh
bCkKICAiUmVjb3JkIGFuIHVuaXF1ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCjs7IEZJWE1F
OiBgZ3R5cGUtb2YnIENQVSBjb3N0IGlzIHByb3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9m
IHR5cGVzCjs7IGRlZmluZWQgd2l0aCBgY2wtZGVmdHlwZScsIHNvIHRoZSBtb3JlIHBvcHVs
YXIgaXQgZ2V0cywgdGhlIHNsb3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5kIG9mIGNvdXJzZSwg
dGhlIGNvc3Qgb2YgZWFjaCB0eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRlZCwgc28gYSBzaW5n
bGUgImV4cGVuc2l2ZSIgdHlwZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRvd24KOzsgZnVydGhl
ci4KOzsKOzsgVGhlIHVzdWFsIGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxhbWJkYSAoYXJnICZy
ZXN0IGFyZ3MpCjs7ICAgICAobGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlwZW9mIGFyZykgcHJl
Y29tcHV0ZWQtbWV0aG9kcy10YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7OyAgICAgICAgICAg
KGFwcGx5IGYgYXJnIGFyZ3MpCjs7ICAgICAgICAgOzsgU2xvdyBjYXNlIHdoZW4gZW5jb3Vu
dGVyaW5nIGEgbmV3IHR5cGUKOzsgICAgICAgICAuLi4pKSkKOzsKOzsgd2hlcmUgb2Z0ZW4g
dGhlIG1vc3QgZXhwZW5zaXZlIHBhcnQgaXMgYCZyZXN0YCAod2hpY2ggaGFzIHRvCjs7IGFs
bG9jYXRlIGEgbGlzdCBmb3IgdGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50cyksCjs7Cjs7IFNv
IHdlJ3JlIHRhbGtpbmcgYWJvdXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJlc3QgKyBjbC10eXBl
LW9mICsgZ2V0aGFzaCArIGlmICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1bmN0aW9uIHRoYXQg
bG9vcHMgb3ZlciBOIHR5cGVzLCBjYWxsaW5nIGBjbC10eXBlcGAgb24gZWFjaAo7OyBvbmUg
b2YgdGhlbSAoYGNsLXR5cGVwYCBpdHNlbGYgYmVpbmcgYSByZWN1cnNpdmUgZnVuY3Rpb24g
dGhhdAo7OyBiYXNpY2FsbHkgaW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5ndWFnZSkuICBUaGlz
IGlzIGdvaW5nIHRvIHNsb3cKOzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNpZ25pZmljYW50bHkg
Zm9yIHRob3NlIGdlbmVyaWMgZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBhIG1ldGhvZCB0aGF0
IGRpc3BhdGNoZXMgb24gYSB1c2VyIGRlZmluZWQgdHlwZSwgY29tcGFyZWQgdG8KOzsgdGhv
c2UgdGhhdCBkb24ndC4KOzsKOzsgSXQncyBub3QgdGhlIGVuZCBvZiB0aGUgd29ybGQsIGVz
cGVjaWFsbHkgYmVjYXVzZSB0aGVyZSdzIGEgbG90IG9mCjs7IG9wcG9ydHVuaXRpZXMgZm9y
IG9wdGltaXphdGlvbnMgaW4gdGhlcmUsIGJ1dCBpdCdzIHNvbWV0aGluZyB0bwo7OyBrZWVw
IGluIG1pbmQuCgo7OyAoZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKOzsgICAiUmV0dXJu
IHRoZSB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4KOzsgUmV0dXJuIGFuIHVuaXF1ZSBsaXN0
IG9mIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCjs7IG1vc3Qg
c3BlY2lmaWMgdHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKOzsgICA7OyBJZ25vcmUgcmVj
dXJzaXZlIGNhbGwgb24gdGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5
Cjs7ICAgOzsgb2NjdXIgd2hlbiBhIHBhcmVudCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIg
YW4gb2JqZWN0J3MgdHlwZSBpcwo7OyAgIDs7IHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJl
bi4KOzsgICAodW5sZXNzIChlcSBvYmplY3QgY2wtLXR5cGUtb2JqZWN0KQo7OyAgICAgKGxl
dCAoKGNsLS10eXBlLW9iamVjdCBvYmplY3QpCjs7ICAgICAgICAgICAoZm91bmQgKGxpc3Qg
KGNsLXR5cGUtb2Ygb2JqZWN0KSkpKQo7OyAgICAgICA7OyBDb2xsZWN0IGFsbCB0eXBlcyBP
QkpFQ1QgYmVsb25ncyB0by4KOzsgICAgICAgKGRvbGlzdCAodHlwZSBjbC0tdHlwZS1saXN0
KQo7OyAgICAgICAgIChpZiAoY2wtdHlwZXAgb2JqZWN0IHR5cGUpCjs7ICAgICAgICAgICAg
IChwdXNoIHR5cGUgZm91bmQpKSkKOzsgICAgICAgOzsgUmV0dXJuIGFuIHVuaXF1ZSB2YWx1
ZSBvZiB0eXBlLgo7OyAgICAgICAod2l0aC1tZW1vaXphdGlvbiAoZ2V0aGFzaCBmb3VuZCBj
bC0tdHlwZS11bmlxdWUpCjs7ICAgICAgICAgZm91bmQpKSkpCgo7OyBBc3N1bWluZyB0aGF0
IGBjbC0tdHlwZS1saXN0JyBpcyBwcm9wZXJseSBzb3J0ZWQgZnJvbSBtb3N0IHNwZWNpZmlj
Cjs7IHR5cGVzIHRvIGxlYXN0IHNwZWNpZmljIG9uZXMsIHdoaWNoIHNob3VsZCBiZSBndWFy
YW50ZWVkIGJ5Cjs7IGBtZXJnZS1vcmRlcmVkLWxpc3QnIGluIGBjbC0tdHlwZS1nZW5lcmFs
aXplJyB0aGlzIHZlcmlvbnMgb2YKOzsgYGNsLXR5cGVzLW9mJyB0cmllcyBzZXF1ZW50aWFs
bHkgZWFjaCB0eXBlIGluIGBjbC0tdHlwZS1saXN0JywgYnV0Cjs7IHN0b3BzIG9uIHRoZSBm
aXJzdCB0eXBlIHRoYXQgbWF0Y2hlcyBhbmQgcmV0dXJucyB0aGUgcGFyZW50cyBvZiB0aGUK
OzsgdHlwZSBwbHVzIHRoZSBidWlsdGluIHR5cGUgb2YgT0JKRUNULiAgSWYgbm8gdHlwZSBp
cyBmb3VuZCwgcmV0dXJuCjs7IG5pbCB0byBmYWxsYmFjayB0byB0aGUgInR5cGVvZiIgZ2Vu
ZXJhbGl6ZXIuCihkZWZ1biBjbC10eXBlcy1vZiAob2JqZWN0KQogICJSZXR1cm4gdGhlIHVz
ZXIgZGVmaW5lZCB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0bywgb3IgbmlsIGlmIG5vbmUuClJl
dHVybiBhbiB1bmlxdWUgbGlzdCBvZiB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0bywgb3JkZXJl
ZCBmcm9tIHRoZQptb3N0IHNwZWNpZmljIHR5cGUgdG8gdGhlIG1vc3QgZ2VuZXJhbC4iCiAg
OzsgSWdub3JlIHJlY3Vyc2l2ZSBjYWxsIG9uIHRoZSBzYW1lIE9CSkVDVCwgd2hpY2ggY2Fu
IGxlZ2l0aW1hdGVseQogIDs7IG9jY3VyIHdoZW4gYSBwYXJlbnQgdHlwZSBpcyBjaGVja2lu
ZyB3aGV0aGVyIGFuIG9iamVjdCdzIHR5cGUgaXMKICA7OyB0aGF0IG9mIG9uZSBvZiBpdHMg
Y2hpbGRyZW4uCiAgKHVubGVzcyAoZXEgb2JqZWN0IGNsLS10eXBlLW9iamVjdCkKICAgIChs
ZXQgKChjbC0tdHlwZS1vYmplY3Qgb2JqZWN0KQogICAgICAgICAgKHR5cGVzIGNsLS10eXBl
LWxpc3QpCiAgICAgICAgICAoZm91bmQgbmlsKSkKICAgICAgOzsgVHJ5IGFsbCB0eXBlcyB1
bnRpbCBvbmUgaXMgZm91bmQgT0JKRUNUIGJlbG9uZ3MgdG8uCiAgICAgICh3aGlsZSAoYW5k
IHR5cGVzIChub3QgZm91bmQpKQogICAgICAgIChpZiAoY2wtdHlwZXAgb2JqZWN0IChjYXIg
dHlwZXMpKQogICAgICAgICAgICA7OyBJZiBPQkpFQ1QgYmVsb25ncyB0byB0eXBlLCBhc3N1
bWluZyB0eXBlIGlzIHRoZSBtb3N0CiAgICAgICAgICAgIDs7IHBvc3NpYmxlIHNwZWNpZmlj
IHR5cGUgb2YgT0JKRUNULCB0aGUgbGlzdCBvZiB0eXBlcwogICAgICAgICAgICA7OyBPQkpF
Q1RTIGJlbG9uZ3MgdG8gc2hvdWxkIGJlIGVxdWFsIHRvIHRoZSBsaXN0IG9mIHR5cGUKICAg
ICAgICAgICAgOzsgcGFyZW50cywgcGx1cyB0aGUgYnVpbHRpbiB0eXBlIG9mIE9CSkVDVC4K
ICAgICAgICAgICAgKHNldHEgZm91bmQgKG5jb25jIChjbC10eXBlLXBhcmVudHMgKGNhciB0
eXBlcykpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGlzdCAoY2wtdHlwZS1v
ZiBvYmplY3QpKSkpCiAgICAgICAgICAoc2V0cSB0eXBlcyAoY2RyIHR5cGVzKSkpKQogICAg
ICAoaWYgZm91bmQKICAgICAgICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUuCiAgICAg
ICAgICAod2l0aC1tZW1vaXphdGlvbiAoZ2V0aGFzaCBmb3VuZCBjbC0tdHlwZS11bmlxdWUp
CiAgICAgICAgICAgIGZvdW5kKSkpKSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGRl
ZnZhciBjbC0tdHlwZS1zcGVjaWFsaXplcnMgKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXEp
CiAgIk1lbW9pemUgdHlwZSBzcGVjaWFsaXplcnMuClZhbHVlcyBhcmUgcmVmcmVzaGVkIGZv
bGxvd2luZyB0aGUgZGVmaW5pdGlvbiBvciByZW1vdmFsIG9mIHR5cGVzLiIpCgooZGVmdW4g
Y2wtLXR5cGUtcmVzZXQtc3BlY2lhbGl6ZXJzIChuYW1lKQogICJSZW1vdmUgYWxsIGNhY2hl
ZCB2YWx1ZSBvZiBzcGVjaWFsaXplcnMgcmVsYXRlZCB0byB0eXBlIHdpdGggTkFNRS4iCiAg
KG1hcGhhc2ggKGxhbWJkYSAoa2V5IF8pCiAgICAgICAgICAgICAoaWYgKG1lbXEgbmFtZSBr
ZXkpCiAgICAgICAgICAgICAgICAgKHJlbWhhc2gga2V5IGNsLS10eXBlLXNwZWNpYWxpemVy
cykpKQogICAgICAgICAgIGNsLS10eXBlLXNwZWNpYWxpemVycykpCgooZGVmdW4gY2wtLXR5
cGUtc3BlY2lhbGl6ZXJzICh0YWcgJnJlc3QgXykKICAiSWYgVEFHIGlzIGEgdHlwZSwgcmV0
dXJuIGl0cyBzcGVjaWFsaXplcnMuIgogIDs7IFRoaXMgZnVuY3Rpb24gaXMgb25seSBldmVy
IGNhbGxlZCB3aXRoICJ0YWdjb2RlcyIgcmV0dXJuZWQgYnkKICA7OyBgY2wtdHlwZS1vZics
IHNvIHRoZSBgY2wtdHlwZS1wJyB0ZXN0IGlzIHJlZHVuZGFudC4KICAoYW5kIChjb25zcCB0
YWcpIDs7IChjbC10eXBlLXAgKGNhciB0YWcpKQogICAgICAgKHdpdGgtbWVtb2l6YXRpb24g
KGdldGhhc2ggdGFnIGNsLS10eXBlLXNwZWNpYWxpemVycykKICAgICAgICAgOzsgVG8gZmlu
ZCB0aGUgbW9zdCBwb3NzaWJsZSBzcGVjaWZpYyB0eXBlIG9mIGFuIG9iamVjdCwgaXQKICAg
ICAgICAgOzsgaXMgY3JpdGljYWwgdG8gaGF2ZSBzcGVjaWFsaXplcnMgb3JkZXJlZCBmcm9t
IHRoZSBtb3N0CiAgICAgICAgIDs7IHNwZWNpZmljIHBvc3NpYmxlIHR5cGUgdG8gdGhlIG1v
cmUgZ2VuZXJhbCB0eXBlLgogICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cyAobWFwY2Fy
ICMnY2wtdHlwZS1wYXJlbnRzIHRhZykpKSkpCgooY2wtZ2VuZXJpYy1kZWZpbmUtZ2VuZXJh
bGl6ZXIgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIKICAyMCA7OyAidHlwZW9mIiA8ICJjbC10eXBl
cy1vZiIgPCAiaGVhZCIgcHJpb3JpdHkKICAobGFtYmRhIChvYmogJnJlc3QgXykgYChjbC10
eXBlcy1vZiAsb2JqKSkKICAjJ2NsLS10eXBlLXNwZWNpYWxpemVycykKCihjbC1kZWZtZXRo
b2QgY2wtZ2VuZXJpYy1nZW5lcmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1vZiIgKHR5cGUp
CiAgIlN1cHBvcnQgZm9yIGRpc3BhdGNoIG9uIHR5cGVzLiIKICAoaWYgKGNsLXR5cGUtcCB0
eXBlKQogICAgICAobGlzdCBjbC0tdHlwZS1nZW5lcmFsaXplcikKICAgIChjbC1jYWxsLW5l
eHQtbWV0aG9kKSkpCgo7OzsgU29tZSB0ZXN0cwo7OwonKHByb2duCiAgIChjbC1kZWZ0eXBl
MiB1bnNpZ25lZC1ieXRlICgmb3B0aW9uYWwgYml0cykKICAgICAiVW5zaWduZWQgaW50ZWdl
ci4iCiAgICAgYChpbnRlZ2VyIDAgLChpZiAoZXEgYml0cyAnKikgYml0cyAoMS0gKGFzaCAx
IGJpdHMpKSkpKQoKICAgKGNsLWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICJV
bnNpZ25lZCAxNi1iaXRzIGludGVnZXIuIgogICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVu
c2lnbmVkLWJ5dGUpKQogICAgICcodW5zaWduZWQtYnl0ZSAxNikpCgogICAoY2wtZGVmdHlw
ZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgICAiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuIgog
ICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVuc2lnbmVkLTE2Yml0cykpCiAgICAgJyh1bnNp
Z25lZC1ieXRlIDgpKQogICAKICAgKGNsLXR5cGVzLW9mIDEwMCkKICAgOzsgKHVuc2lnbmVk
LThiaXRzIHVuc2lnbmVkLTE2Yml0cyB1bnNpZ25lZC1ieXRlIGZpeG51bSkKCiAgIChjbC10
eXBlcy1vZiAyNTYpCiAgIDs7ICh1bnNpZ25lZC0xNmJpdHMgdW5zaWduZWQtYnl0ZSBmaXhu
dW0pCgogICAoY2wtdHlwZXMtb2YgbW9zdC1wb3NpdGl2ZS1maXhudW0pCiAgIDs7ICh1bnNp
Z25lZC1ieXRlIGZpeG51bSkKIAogICAoY2wtZGVmbWV0aG9kIG15LWZvbyAoKF9uIHVuc2ln
bmVkLWJ5dGUpKQogICAgIChmb3JtYXQgInVuc2lnbmVkIikpCgogICAoY2wtZGVmbWV0aG9k
IG15LWZvbyAoKF9uIHVuc2lnbmVkLTE2Yml0cykpCiAgICAgKGZvcm1hdCAidW5zaWduZWQg
MTZiaXRzIC0gYWxzbyAlcyIKICAgICAgICAgICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkp
CgogICAoY2wtZGVmbWV0aG9kIG15LWZvbyAoKF9uIHVuc2lnbmVkLThiaXRzKSkKICAgICAo
Zm9ybWF0ICJ1bnNpZ25lZCA4Yml0cyAtIGFsc28gJXMiCiAgICAgICAgICAgICAoY2wtY2Fs
bC1uZXh0LW1ldGhvZCkpKQogICAKICAgKG15LWZvbyAxMDApCiAgIDs7ICJ1bnNpZ25lZCA4
Yml0cyAtIGFsc28gdW5zaWduZWQiCgogICAobXktZm9vIDI1NikKICAgOzsgInVuc2lnbmVk
IDE2Yml0cyAtIGFsc28gdW5zaWduZWQgOGJpdHMgLSBhbHNvIHVuc2lnbmVkIgoKICAgKG15
LWZvbyBtb3N0LXBvc2l0aXZlLWZpeG51bSkKICAgOzsgInVuc2lnbmVkIgoKICAgKGNsLWRl
ZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICJVbnNpZ25lZCAxNi1iaXRzIGludGVn
ZXIuIgogICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVuc2lnbmVkLThiaXRzKSkKICAgICAn
KHVuc2lnbmVkLWJ5dGUgMTYpKQogICA7OyBJbnZhbGlkIERBRyBlcnJvcgogICAKICApCg==
--------------NmUF7puYso0yKcC0qzFBhzuT--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 16 Apr 2025 15:43:01 +0000
Resent-Message-ID: <handler.77725.B77725.17448181487239 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17448181487239
(code B ref 77725); Wed, 16 Apr 2025 15:43:01 +0000
Received: (at 77725) by debbugs.gnu.org; 16 Apr 2025 15:42:28 +0000
Received: from localhost ([127.0.0.1]:40618 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u54uB-0001sh-Li
for submit <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:42:28 -0400
Received: from smtp-15.smtpout.orange.fr ([80.12.242.15]:53949
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u54u7-0001rp-3T
for 77725 <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:42:25 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 54tduUjyYtvMG54tgu2SnR; Wed, 16 Apr 2025 17:41:59 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744818119;
bh=oS4g5MBbq40ywNiAlAtv4P5PQp3MBuBMb3MHNVJPLKw=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=aIlTuNgWWYyfCN3Aav/K3Dpmqk06d/ZauU1lP4Qwc8EFLLj8e+4x3CzgB9Y5h2kjk
tfc8ya2oUntRuEWgHyiy0GuG1tYJujMouR0U2mNioMqrPomBpQNuBW+Olz0E5kmS0Z
Izu8pXA9ij9oyvKSeYMUVN42le39SINruPRMPs/oy4cbbVNzGGk8tkrDHWkPBgvAL/
7mmx6a5KyM59swuiADI4gnjg41TsVBDOHX077lY5lyq4PSCCWwnm+Uxbl3xWojdPIw
2LgQgNQZSABPeyLJGux3gFM/emICFgFu4eIYEDYLsu8oaKsJEhAkPhl42paAHvd1OE
LNclT9zFwY81g==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Wed, 16 Apr 2025 17:41:59 +0200
X-ME-IP: 90.112.40.65
Message-ID: <e910b889-2d57-41d5-a048-713e6dfb8b58@HIDDEN>
Date: Wed, 16 Apr 2025 17:42:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: David Ponce <da_vid@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
[...]
> Please find attached a first attempt at a cl-types.el to be merged in
> cl-lib. Please feel free to propose new names if mine are not good.
>
> For now, the new `cl-deftype' is named `cl-deftype2' for testing
> without impacting the existing environment.
>
> I tried to consistent at using the `cl-type-' prefix (or `cl--type-'
> for internals). But some names are very close to already existing
> ones, like 'cl-type-p' vs. `cl-typep'. There is also a collision with
> the name `cl-type-of', already used for a builtin function, so I used
> the name `cl-types-of' which also better represent that this function
> returns a list of types.
>
> The new code is also better at handling errors. It should detect most
> of the possible errors, and will restore the current environnement on
> error. I also tried to improve cl-types-of. Please read my comments
> in the code.
>
> WDYT?
I also have a question regarding the "typeof" generalizer which is defined
like this in cl-generic:
(cl-generic-define-generalizer cl--generic-typeof-generalizer
10 (lambda (name &rest _) `(cl-type-of ,name))
#'cl--generic-type-specializers)
(cl-defmethod cl-generic-generalizers :extra "typeof" (type)
"Support for dispatch on types.
This currently works for built-in types and types built on top of records."
;; FIXME: Add support for other "types" accepted by `cl-typep' such
;; as `character', `face', `keyword', ...?
(or
(and (symbolp type)
(not (eq type t)) ;; Handled by the `t-generalizer'.
(let ((class (cl--find-class type)))
(memq (type-of class)
'(built-in-class cl-structure-class eieio--class)))
(list cl--generic-typeof-generalizer))
(cl-call-next-method)))
The proposed "cl-types-of" generalizer must have a higher priority than
"typof" to correctly takes precedence over built-in types.
But, what about the defstruct and defclass types? Shouldn't such types
have higher priority than cl-deftype and builtin types?
I wouldn't want "cl-types-of" to have too much of a performance impact on
method dispatch for defstruct and defclass types, unless it's really
necessary.
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 16 Apr 2025 19:57:03 +0000
Resent-Message-ID: <handler.77725.B77725.17448334055497 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17448334055497
(code B ref 77725); Wed, 16 Apr 2025 19:57:03 +0000
Received: (at 77725) by debbugs.gnu.org; 16 Apr 2025 19:56:45 +0000
Received: from localhost ([127.0.0.1]:42539 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u58sG-0001Qa-Nt
for submit <at> debbugs.gnu.org; Wed, 16 Apr 2025 15:56:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2996)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u58sB-0001PG-Pv
for 77725 <at> debbugs.gnu.org; Wed, 16 Apr 2025 15:56:43 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 67253441E98;
Wed, 16 Apr 2025 15:56:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744833391;
bh=qIv0EnC0qNRahph0CPsRQ95kAOn+flXgx+ZdutlL9IY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=QZNaNuShutAGIhjv4x51I8eBUQEj/SB7gWMa5P5VOmoTDyDtg+nqPnbYTNDVL3nis
Z/Lw1qb0Nxlu4vbkZprISVOxKC0b+q/hKuHKwul1I+kjD9kVHg15HqZRDAjd9UWZ3e
7WDIWs2ZJ5Hv0gNZFvnq/YuQ1+MYVbn5ozPIvJ+jKIERKZGSz9xePGlEB/v5oMjcsv
pCwvp2gqwiQqy61032XLKZX28WifVMLac6Vwku45MgNZ90/PVt5kbmMB31GJraaxF4
n14cd+h4rPO9zD1TMj4PEw46d4ZBDM7iAtufACT+JEpXJJxlrRZ3pdV8GO0pROajDw
hslo5S4pJvh8g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 360634418DA;
Wed, 16 Apr 2025 15:56:31 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC6F11205FA;
Wed, 16 Apr 2025 15:56:30 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Message-ID: <jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Date: Wed, 16 Apr 2025 15:56:30 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.201 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Please find attached a first attempt at a cl-types.el to be merged in
> cl-lib. Please feel free to propose new names if mine are not good.
>
> For now, the new `cl-deftype' is named `cl-deftype2' for testing
> without impacting the existing environment.
=F0=9F=91=8D=F0=9F=8F=BE
> so I used the name `cl-types-of' which also better represent that this
> function returns a list of types.
+1
> WDYT?
See comments below.
> The proposed "cl-types-of" generalizer must have a higher priority than
> "typof" to correctly takes precedence over built-in types.
That's right.
> But, what about the defstruct and defclass types? Shouldn't such types
> have higher priority than cl-deftype and builtin types?
Actually, since Emacs-26 `(cl-)type-of` returns the proper struct type
for both defstruct and defclass types, so they both use the
`cl--generic-typeof-generalizer`.
[ That's still not the case for OClosures, sadly. ]
> I wouldn't want "cl-types-of" to have too much of a performance impact on
> method dispatch for defstruct and defclass types, unless it's really
> necessary.
The cost is doesn't depend on priority, it depends only on which
generalizers are used for which generic-functions: a generic function
whose methods don't use cl-types will not be affected at all. A generic
function which does have at least one method dispatching on a cl-type
will be affected, even if you never call it with an object of such cl-type.
> (defun cl-type-p (object)
> "Return non-nil if OBJECT is a used defined type.
> That is, a type of class `cl-type-class'."
> (and (symbolp object)
> (eq (type-of (cl-find-class object)) 'cl-type-class)))
Hmm... yeah... names...
Then again, I don't think we have an equivalent function to test if
a type is a bultin type or a struct type or a defclass type or an
OClosure type, so let's push this to the "cl--" namespace.
> (cl-defstruct
> (cl-type-class
> (:include cl--class)
> (:noinline t)
> (:constructor nil)
> (:constructor cl--type-class-make
> (name
> docstring
> parent-types
> &aux (parents
> (mapcar
> (lambda (type)
> (cl-check-type type (satisfies cl-type-p))
> (cl-find-class type))
> parent-types))))
> (:copier nil))
> "Type descriptors for user defined types.")
I'm thinking it might be useful to accept builtin types as parents.
E.g. we could make `cl-types-p` skip testing those cl-types whose parents
are incompatible with the output of `cl-type-p`.
I'd add a FIXME in there noting that the `cl-deftype-handler` property
should arguably be turned into a field of this struct (but it has
performance and compatibility implications, so let's not make that
change for now).
> (defun cl-type-parents (name)
> "Get parents of type with NAME.
> NAME is a symbol representing a type."
> (cl--class-allparents (cl-find-class name)))
Let's push this to "cl--" as well.
> (defun cl-type-children (name)
> "Get children of the type with NAME.
> NAME is a symbol representing a type.
> Return a possibly empty list of types."
> (cl-check-type name (satisfies cl-type-p))
> (let (children)
> (dolist (elt cl--type-list)
> (or (eq name elt)
> (if (memq name (cl-type-parents elt))
> (push elt children))))
> children))
Same.
> (defun cl--type-generalize (name arglist body)
> "Generalize type with NAME for method dispatching.
> ARGLIST and BODY are passed to `cl-deftype'."
> (let ((oldtlist (copy-sequence cl--type-list))
> (oldplist (copy-sequence (symbol-plist name))))
> (condition-case err
> (pcase-let* ((`(,decls . ,body) (macroexp-parse-body body))
> (docstring (if (stringp (car decls))
> (pop decls)
> (cdr (assq :documentation decls))))
> (decls (cdr (assq 'declare decls)))
> (parents (cdr (assq 'subtype-of decls)))
Since we use the word "parents" everywhere, maybe we should look for
`parents` rather than `subtype-of`?
> (class (cl-find-class name))
> (reged (memq name cl--type-list)))
> (if (null class)
> (or (null reged)
> (error "Type generalized, but doesn't exist"))
> (or reged "Type exists, but not generalized")
I think there's an `error` missing here or something.
> (or (eq (type-of class) 'cl-type-class)
> (error "Type in another class: %S" (type-of class))))
> (or (listp parents) (setq parents (list parents)))
> (if (memq name parents)
> (error "Type in parents: %S" parents))
Not sure how useful is this test.
> ;; Setup a type descriptor for NAME. Can't use `setf' with
> ;; `cl-find-class', so fallback to plain `put' to set the
> ;; `cl--class' symbol property.
> (put name 'cl--class
> (cl--type-class-make name docstring parents))
Better use `setf` (with `cl--find-class`).
> ;; Clear cached value of specializers with NAME.
> (if class
> (cl--type-reset-specializers name)
> ;; Record new type.
> (push name cl--type-list))
Shouldn't we test `reged` before `push`ing?
Also, I think we should skip those types whose arglist is not empty
(and probably signal an error if `subtype-of` is specified at the same
time as a non-empty arglist).
> ;; Keep most specific types before more general types.
> (setq cl--type-list (merge-ordered-lists
> (cl--type-dag)
> (lambda (g)
> (error "Invalid DAG, %S" g))))
Why do we need sorting? Ah, it's so as to avoid sorting in
`cl-types-of`? Maybe clarify it in the comment, then.
> ;; Return the form to declare the type.
> `(cl-eval-when (compile load eval)
> (define-symbol-prop ',name 'cl-deftype-handler
> (cl-function
> (lambda (&cl-defs ('*) ,@arglist)
> ,docstring
> ,@body)))))
Hmm... wait, so all the code before is executed only during
macro-expansion and not at run-time? That doesn't sound right.
> (defmacro cl-type-undefine (name)
> "Remove the definitions of type with NAME.
> NAME is an unquoted symbol representing a type.
> Signal an error if other types inherit from NAME."
> `(progn
> (cl-check-type ',name (satisfies cl-type-p))
> (cl--type-undefine ',name)))
We don't have that for other types. I understand it's somewhat
dangerous for the other types and not for this one, but I still wonder
if we need it.
> ;; Assuming that `cl--type-list' is properly sorted from most specific
> ;; types to least specific ones, which should be guaranteed by
> ;; `merge-ordered-list' in `cl--type-generalize' this verions of
> ;; `cl-types-of' tries sequentially each type in `cl--type-list', but
> ;; stops on the first type that matches and returns the parents of the
> ;; type plus the builtin type of OBJECT. If no type is found, return
> ;; nil to fallback to the "typeof" generalizer.
That doesn't sound right: it works only if there are no types which are
overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
We may be able to use the `subtype-of` info to skip some types (e.g. we
don't need to test the parents, or if we traverse the list in the other
direction, we don't need to test FOO if we already saw that the object
failed the test for one of FOO's parents), but in general we'll have to
check them all: we definitely can't stop at the first successful check.
Stefan
> (defvar cl--type-specializers (make-hash-table :test 'eq)
> "Memoize type specializers.
> Values are refreshed following the definition or removal of types.")
>
> (defun cl--type-reset-specializers (name)
> "Remove all cached value of specializers related to type with NAME."
> (maphash (lambda (key _)
> (if (memq name key)
> (remhash key cl--type-specializers)))
> cl--type-specializers))
BTW, you can also make `cl-types-of` return directly the complete list
of types+allparents, i.e. the ordered list of specializers. And then
your `cl--type-specializers` function could turn into the identity.
> ;;; Some tests
> ;;
> '(progn
> (cl-deftype2 unsigned-byte (&optional bits)
> "Unsigned integer."
> `(integer 0 ,(if (eq bits '*) bits (1- (ash 1 bits)))))
>
> (cl-deftype2 unsigned-16bits ()
> "Unsigned 16-bits integer."
> (declare (subtype-of unsigned-byte))
> '(unsigned-byte 16))
>
> (cl-deftype2 unsigned-8bits ()
> "Unsigned 8-bits integer."
> (declare (subtype-of unsigned-16bits))
> '(unsigned-byte 8))
I suggest to define something like `multiples-of-2`, `multiples-of-3`,
and `multiples-of-4`, so as to test more complex relationships between
types (with overlap but not inclusion).
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 17 Apr 2025 12:31:01 +0000
Resent-Message-ID: <handler.77725.B77725.17448930234756 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17448930234756
(code B ref 77725); Thu, 17 Apr 2025 12:31:01 +0000
Received: (at 77725) by debbugs.gnu.org; 17 Apr 2025 12:30:23 +0000
Received: from localhost ([127.0.0.1]:46110 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5ONp-0001EV-AR
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 08:30:22 -0400
Received: from smtp-69.smtpout.orange.fr ([80.12.242.69]:60881
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u5ONj-0001Bp-Pv
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 08:30:19 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 5ONbu3W2yukJt5ONfumaMJ; Thu, 17 Apr 2025 14:30:13 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744893013;
bh=jCDpaDrVLruUfA4YPXct/7djE3Qk8M/0HdIFm4+1rKU=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=hNFgD2Vq7/gR1gFLRWhuNh7UzKu02LzXDMBBeTf+e+ejGn9HPYYRRNJJsO4BcUvcW
7M0p8pp1CRFmWAed9Mb5YUCmbppD990SiH3RUwKFjZjL5wgNiOZDyIVJBZ+hIbt3+e
VaZFseV++XvAUKF6C2+lize75ZnSVmpi6b9VD9jiHn/sUWe6CykmVGl0hujx+Zf+lW
7ASARKr1Jua9vxxSsdn9dRgb+IaTy5WgofRrZ2meSvYSSTQaq0e0cij2/6MB2U3vjO
YO25cSl15oWgUuB4BPiEoJuaYVg7V4gOrV4j7rUdZiQmhwDmMxxiPdY4fXABfT8upX
bWY35+cTLqdew==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Thu, 17 Apr 2025 14:30:13 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------PB4Obs9l4nluomYQAxkWHcmP"
Message-ID: <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
Date: Thu, 17 Apr 2025 14:30:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------PB4Obs9l4nluomYQAxkWHcmP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
[...]
> The cost is doesn't depend on priority, it depends only on which
> generalizers are used for which generic-functions: a generic function
> whose methods don't use cl-types will not be affected at all. A generic
> function which does have at least one method dispatching on a cl-type
> will be affected, even if you never call it with an object of such cl-type.
Good to know :-)
>> (defun cl-type-p (object)
>> "Return non-nil if OBJECT is a used defined type.
>> That is, a type of class `cl-type-class'."
>> (and (symbolp object)
>> (eq (type-of (cl-find-class object)) 'cl-type-class)))
>
> Hmm... yeah... names...
>
> Then again, I don't think we have an equivalent function to test if
> a type is a bultin type or a struct type or a defclass type or an
> OClosure type, so let's push this to the "cl--" namespace.
Done.
>> (cl-defstruct
>> (cl-type-class
>> (:include cl--class)
>> (:noinline t)
>> (:constructor nil)
>> (:constructor cl--type-class-make
>> (name
>> docstring
>> parent-types
>> &aux (parents
>> (mapcar
>> (lambda (type)
>> (cl-check-type type (satisfies cl-type-p))
>> (cl-find-class type))
>> parent-types))))
>> (:copier nil))
>> "Type descriptors for user defined types.")
>
> I'm thinking it might be useful to accept builtin types as parents.
> E.g. we could make `cl-types-p` skip testing those cl-types whose parents
> are incompatible with the output of `cl-type-p`.
I tried to do that, but I am not sure I well understood your point.
Please let me know if the code is what you expect.
> I'd add a FIXME in there noting that the `cl-deftype-handler` property
> should arguably be turned into a field of this struct (but it has
> performance and compatibility implications, so let's not make that
> change for now).
Done.
>> (defun cl-type-parents (name)
>> "Get parents of type with NAME.
>> NAME is a symbol representing a type."
>> (cl--class-allparents (cl-find-class name)))
>
> Let's push this to "cl--" as well.
Done. As it is now internal, I used a macro to reduce function calls
in cl-types-of (see your point below about making `cl-types-of`
returns directly the complete list of types+allparents).
>
>> (defun cl-type-children (name)
>> "Get children of the type with NAME.
>> NAME is a symbol representing a type.
>> Return a possibly empty list of types."
>> (cl-check-type name (satisfies cl-type-p))
>> (let (children)
>> (dolist (elt cl--type-list)
>> (or (eq name elt)
>> (if (memq name (cl-type-parents elt))
>> (push elt children))))
>> children))
>
> Same.
Done.
>> (defun cl--type-generalize (name arglist body)
>> "Generalize type with NAME for method dispatching.
>> ARGLIST and BODY are passed to `cl-deftype'."
>> (let ((oldtlist (copy-sequence cl--type-list))
>> (oldplist (copy-sequence (symbol-plist name))))
>> (condition-case err
>> (pcase-let* ((`(,decls . ,body) (macroexp-parse-body body))
>> (docstring (if (stringp (car decls))
>> (pop decls)
>> (cdr (assq :documentation decls))))
>> (decls (cdr (assq 'declare decls)))
>> (parents (cdr (assq 'subtype-of decls)))
>
> Since we use the word "parents" everywhere, maybe we should look for
> `parents` rather than `subtype-of`?
Make sense. I used parents.
>
>> (class (cl-find-class name))
>> (reged (memq name cl--type-list)))
>> (if (null class)
>> (or (null reged)
>> (error "Type generalized, but doesn't exist"))
>> (or reged "Type exists, but not generalized")
>
> I think there's an `error` missing here or something.
Good catch. Fixed.
>> (or (eq (type-of class) 'cl-type-class)
>> (error "Type in another class: %S" (type-of class))))
>> (or (listp parents) (setq parents (list parents)))
>> (if (memq name parents)
>> (error "Type in parents: %S" parents))
>
> Not sure how useful is this test.
I removed testing if parents is a list, this is always true.
The other test prevents to define a type whose parent is itself.
>> ;; Setup a type descriptor for NAME. Can't use `setf' with
>> ;; `cl-find-class', so fallback to plain `put' to set the
>> ;; `cl--class' symbol property.
>> (put name 'cl--class
>> (cl--type-class-make name docstring parents))
>
> Better use `setf` (with `cl--find-class`).
I switched to `cl--find-class' everywhere for consistency.
>> ;; Clear cached value of specializers with NAME.
>> (if class
>> (cl--type-reset-specializers name)
>> ;; Record new type.
>> (push name cl--type-list))
>
> Shouldn't we test `reged` before `push`ing?
Not sure to understand this point. name needs to be in cl--type-list
before to call merge-ordered-lists on the DAG.
> Also, I think we should skip those types whose arglist is not empty
> (and probably signal an error if `subtype-of` is specified at the same
> time as a non-empty arglist).
Signal an error if arglist and parents are both non-nil.
>> ;; Keep most specific types before more general types.
>> (setq cl--type-list (merge-ordered-lists
>> (cl--type-dag)
>> (lambda (g)
>> (error "Invalid DAG, %S" g))))
>
> Why do we need sorting? Ah, it's so as to avoid sorting in
> `cl-types-of`? Maybe clarify it in the comment, then.
Done.
>> ;; Return the form to declare the type.
>> `(cl-eval-when (compile load eval)
>> (define-symbol-prop ',name 'cl-deftype-handler
>> (cl-function
>> (lambda (&cl-defs ('*) ,@arglist)
>> ,docstring
>> ,@body)))))
>
> Hmm... wait, so all the code before is executed only during
> macro-expansion and not at run-time? That doesn't sound right.
OMG! You are right. I fixed that.
>> (defmacro cl-type-undefine (name)
>> "Remove the definitions of type with NAME.
>> NAME is an unquoted symbol representing a type.
>> Signal an error if other types inherit from NAME."
>> `(progn
>> (cl-check-type ',name (satisfies cl-type-p))
>> (cl--type-undefine ',name)))
>
> We don't have that for other types. I understand it's somewhat
> dangerous for the other types and not for this one, but I still wonder
> if we need it.
I thought it could be useful, for example to cleanup the environment
when you kind of uninstall a library which defined types. Maybe it
could help during tests?
>> ;; Assuming that `cl--type-list' is properly sorted from most specific
>> ;; types to least specific ones, which should be guaranteed by
>> ;; `merge-ordered-list' in `cl--type-generalize' this verions of
>> ;; `cl-types-of' tries sequentially each type in `cl--type-list', but
>> ;; stops on the first type that matches and returns the parents of the
>> ;; type plus the builtin type of OBJECT. If no type is found, return
>> ;; nil to fallback to the "typeof" generalizer.
>
> That doesn't sound right: it works only if there are no types which are
> overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
> We may be able to use the `subtype-of` info to skip some types (e.g. we
> don't need to test the parents, or if we traverse the list in the other
> direction, we don't need to test FOO if we already saw that the object
> failed the test for one of FOO's parents), but in general we'll have to
> check them all: we definitely can't stop at the first successful check.
Good point. But you lost me regarding possible optimizations :-(
I returned to the previous version that check all types.
>> (defvar cl--type-specializers (make-hash-table :test 'eq)
>> "Memoize type specializers.
>> Values are refreshed following the definition or removal of types.")
>>
>> (defun cl--type-reset-specializers (name)
>> "Remove all cached value of specializers related to type with NAME."
>> (maphash (lambda (key _)
>> (if (memq name key)
>> (remhash key cl--type-specializers)))
>> cl--type-specializers))
>
> BTW, you can also make `cl-types-of` return directly the complete list
> of types+allparents, i.e. the ordered list of specializers. And then
> your `cl--type-specializers` function could turn into the identity.
Good idea. I did that, which seems to work well :-)
>> ;;; Some tests
[...]
>
> I suggest to define something like `multiples-of-2`, `multiples-of-3`,
> and `multiples-of-4`, so as to test more complex relationships between
> types (with overlap but not inclusion).
Do you have any examples in mind?
Thank you for your help.
David
--------------PB4Obs9l4nluomYQAxkWHcmP
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl
biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCihldmFsLXdoZW4tY29t
cGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5kLWNsYXNzLgoKCgo7OyBF
eHRlbmQgYGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdoaWNoIGFyZSBhbHNv
IHZhbGlkCjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBnZW5lcmljIGZ1bmN0
aW9uIG1ldGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3MuZ251Lm9yZy9jZ2kv
YnVncmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4gZW50cnkgcG9pbnRz
IGFyZToKOzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBuZXcgZGF0YSB0eXBl
cy4KOzsKOzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IHJldHVybnMgdGhlIHR5cGVzIGFuIG9i
amVjdCBiZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5pbAogICJMaXN0IG9m
IGRlZmluZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuIikKCjs7
IEZJWE1FOiBUaGUgYGNsLWRlZnR5cGUtaGFuZGxlcmAgcHJvcGVydHkgc2hvdWxkIGFyZ3Vh
Ymx5IGJlIHR1cm5lZAo7OyBpbnRvIGEgZmllbGQgb2YgdGhpcyBzdHJ1Y3QgKGJ1dCBpdCBo
YXMgcGVyZm9ybWFuY2UgYW5kCjs7IGNvbXBhdGliaWxpdHkgaW1wbGljYXRpb25zLCBzbyBs
ZXQncyBub3QgbWFrZSB0aGF0IGNoYW5nZSBmb3Igbm93KS4KKGNsLWRlZnN0cnVjdAogICAg
KGNsLXR5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNsYXNzKQogICAgICg6bm9pbmxp
bmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAoOmNvbnN0cnVjdG9yIGNsLS10
eXBlLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAgICAgICAgICAgICAg
ICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5cGVzCiAgICAg
ICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAgICAgICAgICAgICAg
IChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAodHlwZSkKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGNsLS1maW5kLWNsYXNzIHR5cGUpCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiVW5rbm93biB0eXBlOiAl
UyIgdHlwZSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMpKSkp
CiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3IgdHlwZXMgZGVm
aW5lZCBieSBgY2wtZGVmdHlwZScuIikKCihkZWZ1biBjbC0tdHlwZS1wIChvYmplY3QpCiAg
IlJldHVybiBub24tbmlsIGlmIE9CSkVDVCBpcyBhIHVzZWQgZGVmaW5lZCB0eXBlLgpUaGF0
IGlzLCBhIHR5cGUgb2YgY2xhc3MgYGNsLXR5cGUtY2xhc3MnLiIKICAoYW5kIChzeW1ib2xw
IG9iamVjdCkKICAgICAgIChjbC10eXBlcCAoY2wtLWZpbmQtY2xhc3Mgb2JqZWN0KSAnY2wt
dHlwZS1jbGFzcykpKQoKKGRlZm1hY3JvIGNsLS10eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdl
dCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2Vu
dGluZyBhIHR5cGUuIgogIGAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNz
ICxuYW1lKSkpCgooZGVmdW4gY2wtLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGls
ZHJlbiBvZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50
aW5nIGEgdHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAg
KGNsLWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogIChsZXQgKGNo
aWxkcmVuKQogICAgKGRvbGlzdCAoZWx0IGNsLS10eXBlLWxpc3QpCiAgICAgIChvciAoZXEg
bmFtZSBlbHQpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSAoY2wtLXR5cGUtcGFyZW50cyBl
bHQpKQogICAgICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVu
KSkKCihkZWZ1biBjbC0tdHlwZS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxp
c3Qgb2YgZGVmaW5lZCB0eXBlcy4iCiAgKG1hcGNhciAobGFtYmRhICh0eXBlKSAoY2wtLWNs
YXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNzIHR5cGUpKSkKICAgICAgICAgIGNsLS10
eXBlLWxpc3QpKQoKOzsgS2VlcCBpdCBmb3Igbm93LCBmb3IgdGVzdGluZy4KKGRlZnVuIGNs
LS10eXBlLXVuZGVmaW5lIChuYW1lKQogICJSZW1vdmUgdGhlIGRlZmluaXRpb24gb2YgdHlw
ZSB3aXRoIE5BTUUuIgogIChkZWNsYXJlLWZ1bmN0aW9uIGNsLXJlbXByb3AgImNsLWV4dHJh
IiAoc3ltYm9sIHByb3BuYW1lKSkKICAod2hlbi1sZXQqICgoY2hpbGRyZW4gKGFuZCAoY2wt
LXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0tdHlwZS1j
aGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMiIGNo
aWxkcmVuKSkKICA7OyBDbGVhciBjYWNoZWQgdmFsdWUgb2Ygc3BlY2lhbGl6ZXJzIHdpdGgg
TkFNRS4KICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXByb3AgbmFt
ZSAnY2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRlbHEgbmFt
ZSBjbC0tdHlwZS1saXN0KSkpCgo7OyBLZWVwIGl0IGZvciBub3csIGZvciB0ZXN0aW5nLgoo
ZGVmbWFjcm8gY2wtdHlwZS11bmRlZmluZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0
aW9ucyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVw
cmVzZW50aW5nIGEgdHlwZS4KU2lnbmFsIGFuIGVycm9yIGlmIG90aGVyIHR5cGVzIGluaGVy
aXQgZnJvbSBOQU1FLiIKICBgKHByb2duCiAgICAgKGNsLWNoZWNrLXR5cGUgJyxuYW1lIChz
YXRpc2ZpZXMgY2wtLXR5cGUtcCkpCiAgICAgKGNsLS10eXBlLXVuZGVmaW5lICcsbmFtZSkp
KQoKKGRlZnVuIGNsLS10eXBlLWdlbmVyYWxpemUgKG5hbWUgYXJnbGlzdCBib2R5KQogICJH
ZW5lcmFsaXplIHR5cGUgd2l0aCBOQU1FIGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuClNlZSBg
Y2wtZGVmdHlwZScgYWJvdXQgQVJHTElTVCBhbmQgQk9EWS4iCiAgKGxldCAoKG9sZHRsaXN0
IChjb3B5LXNlcXVlbmNlIGNsLS10eXBlLWxpc3QpKQogICAgICAgIChvbGRwbGlzdCAoY29w
eS1zZXF1ZW5jZSAoc3ltYm9sLXBsaXN0IG5hbWUpKSkpCiAgICAoY29uZGl0aW9uLWNhc2Ug
ZXJyCiAgICAgICAgKGxldCogKChkZWNscyAgICAgKGNhciAobWFjcm9leHAtcGFyc2UtYm9k
eSBib2R5KSkpCiAgICAgICAgICAgICAgIChkb2NzdHJpbmcgKGlmIChzdHJpbmdwIChjYXIg
ZGVjbHMpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjYXIgZGVjbHMpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3NxIDpkb2N1bWVudGF0aW9uIGRlY2xz
KSkpKQogICAgICAgICAgICAgICAoZGVjbHNwZWNzIChjZHIgKGFzc3EgJ2RlY2xhcmUgZGVj
bHMpKSkKICAgICAgICAgICAgICAgKHBhcmVudHMgICAoY2RyIChhc3NxICdwYXJlbnRzIGRl
Y2xzcGVjcykpKQogICAgICAgICAgICAgICAoY2xhc3MgICAgIChjbC0tZmluZC1jbGFzcyBu
YW1lKSkKICAgICAgICAgICAgICAgKHJlY29yZGVkICAobWVtcSBuYW1lIGNsLS10eXBlLWxp
c3QpKSkKICAgICAgICAgIChhbmQgcGFyZW50cyBhcmdsaXN0CiAgICAgICAgICAgICAgIChl
cnJvciAiUGFyZW50cyBzcGVjaWZpZWQsIGJ1dCBhcmdsaXN0IG5vdCBlbXB0eSIpKQogICAg
ICAgICAgKGlmIChudWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVsbCByZWNvcmRl
ZCkKICAgICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVkLCBidXQgZG9l
c24ndCBleGlzdCIpKQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9yICJUeXBlIGV4
aXN0cywgYnV0IG5vdCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3IgKGNsLXR5cGVw
IGNsYXNzICdjbC10eXBlLWNsYXNzKQogICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGlu
IGFub3RoZXIgY2xhc3M6ICVTIiAodHlwZS1vZiBjbGFzcykpKSkKICAgICAgICAgIChpZiAo
bWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGluIHBhcmVu
dHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9y
IGZvciBOQU1FLgogICAgICAgICAgKHNldGYgKGNsLS1maW5kLWNsYXNzIG5hbWUpCiAgICAg
ICAgICAgICAgICAoY2wtLXR5cGUtY2xhc3MtbWFrZSBuYW1lIGRvY3N0cmluZyBwYXJlbnRz
KSkKICAgICAgICAgIDs7IFJlY29yZCBuZXcgdHlwZSBub3cgdG8gaW5jbHVkZSBpdHMgZGVw
ZW5kZW5jeSBpbiB0aGUgREFHLgogICAgICAgICAgKG9yIGNsYXNzIChwdXNoIG5hbWUgY2wt
LXR5cGUtbGlzdCkpCiAgICAgICAgICA7OyBgY2wtdHlwZXMtb2YnIGl0ZXJhdGVzIHRocm91
Z2ggYWxsIGtub3duIHR5cGVzIHRvIGNvbGxlY3QKICAgICAgICAgIDs7IGFsbCB0aG9zZSBh
biBvYmplY3QgYmVsb25ncyB0bywgc29ydGVkIGZyb20gdGhlIG1vc3QKICAgICAgICAgIDs7
IHNwZWNpZmljIHR5cGUgdG8gdGhlIG1vcmUgZ2VuZXJhbCB0eXBlLiAgU28sIGtlZXAgdGhl
CiAgICAgICAgICA7OyBnbG9iYWwgbGlzdCBpbiB0aGlzIG9yZGVyLgogICAgICAgICAgKHNl
dHEgY2wtLXR5cGUtbGlzdAogICAgICAgICAgICAgICAgKG1lcmdlLW9yZGVyZWQtbGlzdHMK
ICAgICAgICAgICAgICAgICAoY2wtLXR5cGUtZGFnKQogICAgICAgICAgICAgICAgIChsYW1i
ZGEgKF8pIChlcnJvciAiSW52YWxpZCBkZXBlbmRlbmN5IGdyYXBoIikpKSkpCiAgICAgIChl
cnJvcgogICAgICAgOzsgT24gZXJyb3IgcmVzdG9yZSBwcmV2aW91cyBkYXRhLgogICAgICAg
KHNldHEgY2wtLXR5cGUtbGlzdCBvbGR0bGlzdCkKICAgICAgIChzZXRmIChzeW1ib2wtcGxp
c3QgbmFtZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAiRGVmaW5lICVTIGZh
aWxlZDogJXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJvci1tZXNzYWdlLXN0
cmluZyBlcnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gY2wtZGVmdHlwZTIg
KG5hbWUgYXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBhcyBhIG5ldyBkYXRh
IHR5cGUuClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBgY2wtdHlwZWNhc2Un
LCBgY2wtY2hlY2stdHlwZScsIGV0YywKYW5kIGFzIGFyZ3VtZW50IHR5cGUgZm9yIGRpc3Bh
dGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KCkFSR0xJU1QgaXMgYSBDb21tb24g
TGlzcCBhcmd1bWVudCBsaXN0IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5CmBjbC1kZWZtYWNy
bycuICBCT0RZIGZvcm1zIGFyZSBldmFsdWF0ZWQgYW5kIHNob3VsZCByZXR1cm4gYSB0eXBl
CnNwZWNpZmllciB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUgKHNlZSB0aGUgSW5m
byBub2RlIGAoY2wpIFR5cGUKUHJlZGljYXRlcycgaW4gdGhlIEdOVSBFbWFjcyBDb21tb24g
TGlzcCBFbXVsYXRpb24gbWFudWFsKS4KCklmIHRoZXJlIGlzIGEgYGRlY2xhcmUnIGZvcm0g
aW4gQk9EWSwgdGhlIHNwZWMgKHBhcmVudHMgUEFSRU5UUykgaXMKcmVjb2duaXplZCB0byBz
cGVjaWZ5IGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZi4gIEZvcgppbnN0
YW5jZToKCiAgKGNsLWRlZnR5cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25hbCBiaXRzKQog
ICAgXCJVbnNpZ25lZCBpbnRlZ2VyLlwiCiAgICAobGlzdCBcXD0naW50ZWdlciAwIChpZiAo
ZXEgYml0cyBcXD0nKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAoY2wtZGVmdHlw
ZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgIFwiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuXCIK
ICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNpZ25l
ZC1ieXRlIDgpKQoKVGhlIGxpc3Qgb2YgUEFSRU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRoZSBv
cmRlciBvZiBtZXRob2RzIGludm9jYXRpb24sCmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5IGNh
dXNlIGluY29ycmVjdCBvcmRlcmluZyBvZiBtZXRob2RzLCB3aGlsZQpleHRyYW5lb3VzIFBB
UkVOVFMgbWF5IGNhdXNlIHVzZSBvZiBleHRyYW5lb3VzIG1ldGhvZHMuIgogIChkZWNsYXJl
IChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1zdHJpbmcgMykgKGluZGVudCAyKSkKICBgKGNs
LWV2YWwtd2hlbiAoY29tcGlsZSBsb2FkIGV2YWwpCiAgICAgKGNsLS10eXBlLWdlbmVyYWxp
emUgJyxuYW1lICcsYXJnbGlzdCAnLGJvZHkpCiAgICAgKGRlZmluZS1zeW1ib2wtcHJvcCAn
LG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcgogICAgICAgICAgICAgICAgICAgICAgICAgKGNs
LWZ1bmN0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAoJmNsLWRlZnMg
KCcqKSAsQGFyZ2xpc3QpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAsQGJvZHkpKSkp
KQoKOzsgSW50ZXJuYWwgZGF0YSB1c2VkIHRvIGRldGVjdCBlbmRsZXNzIHJlY3Vyc2lvbiBp
biAnY2wtdHlwZS1vZicuCihkZWZ2YXIgY2wtLXR5cGUtb2JqZWN0IChtYWtlLXN5bWJvbCAi
dm9pZCIpKQo7OyBFbnN1cmUgZWFjaCB0eXBlIHNhdGlzZmllcyBgZXFsJy4KKGRlZnZhciBj
bC0tdHlwZS11bmlxdWUgKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXF1YWwpCiAgIlJlY29y
ZCBhbiB1bmlxdWUgdmFsdWUgb2YgZWFjaCB0eXBlLiIpCgo7OyBGSVhNRTogYGNsLXR5cGVz
LW9mJyBDUFUgY29zdCBpcyBwcm9wb3J0aW9uYWwgdG8gdGhlIG51bWJlciBvZiB0eXBlcwo7
OyBkZWZpbmVkIHdpdGggYGNsLWRlZnR5cGUnLCBzbyB0aGUgbW9yZSBwb3B1bGFyIGl0IGdl
dHMsIHRoZSBzbG93ZXIKOzsgaXQgYmVjb21lcy4gIEFuZCBvZiBjb3Vyc2UsIHRoZSBjb3N0
IG9mIGVhY2ggdHlwZSBjaGVjayBpcwo7OyB1bmJvdW5kZWQsIHNvIGEgc2luZ2xlICJleHBl
bnNpdmUiIHR5cGUgY2FuIHNsb3cgZXZlcnl0aGluZyBkb3duCjs7IGZ1cnRoZXIuCjs7Cjs7
IFRoZSB1c3VhbCBkaXNwYXRjaCBpcwo7Owo7OyAgIChsYW1iZGEgKGFyZyAmcmVzdCBhcmdz
KQo7OyAgICAgKGxldCAoKGYgKGdldGhhc2ggKGNsLXR5cGVvZiBhcmcpIHByZWNvbXB1dGVk
LW1ldGhvZHMtdGFibGUpKSkKOzsgICAgICAgKGlmIGYKOzsgICAgICAgICAgIChhcHBseSBm
IGFyZyBhcmdzKQo7OyAgICAgICAgIDs7IFNsb3cgY2FzZSB3aGVuIGVuY291bnRlcmluZyBh
IG5ldyB0eXBlCjs7ICAgICAgICAgLi4uKSkpCjs7Cjs7IHdoZXJlIG9mdGVuIHRoZSBtb3N0
IGV4cGVuc2l2ZSBwYXJ0IGlzIGAmcmVzdGAgKHdoaWNoIGhhcyB0bwo7OyBhbGxvY2F0ZSBh
IGxpc3QgZm9yIHRob3NlIHJlbWFpbmluZyBhcmd1bWVudHMpLAo7Owo7OyBTbyB3ZSdyZSB0
YWxraW5nIGFib3V0IHJlcGxhY2luZwo7Owo7OyAgICZyZXN0ICsgY2wtdHlwZS1vZiArIGdl
dGhhc2ggKyBpZiArIGFwcGx5Cjs7Cjs7IHdpdGggYSBmdW5jdGlvbiB0aGF0IGxvb3BzIG92
ZXIgTiB0eXBlcywgY2FsbGluZyBgY2wtdHlwZXBgIG9uIGVhY2gKOzsgb25lIG9mIHRoZW0g
KGBjbC10eXBlcGAgaXRzZWxmIGJlaW5nIGEgcmVjdXJzaXZlIGZ1bmN0aW9uIHRoYXQKOzsg
YmFzaWNhbGx5IGludGVycHJldHMgdGhlIHR5cGUgbGFuZ3VhZ2UpLiAgVGhpcyBpcyBnb2lu
ZyB0byBzbG93Cjs7IGRvd24gZGlzcGF0Y2ggdmVyeSBzaWduaWZpY2FudGx5IGZvciB0aG9z
ZSBnZW5lcmljIGZ1bmN0aW9ucyB0aGF0Cjs7IGhhdmUgYSBtZXRob2QgdGhhdCBkaXNwYXRj
aGVzIG9uIGEgdXNlciBkZWZpbmVkIHR5cGUsIGNvbXBhcmVkIHRvCjs7IHRob3NlIHRoYXQg
ZG9uJ3QuCjs7Cjs7IEl0J3Mgbm90IHRoZSBlbmQgb2YgdGhlIHdvcmxkLCBlc3BlY2lhbGx5
IGJlY2F1c2UgdGhlcmUncyBhIGxvdCBvZgo7OyBvcHBvcnR1bml0aWVzIGZvciBvcHRpbWl6
YXRpb25zIGluIHRoZXJlLCBidXQgaXQncyBzb21ldGhpbmcgdG8KOzsga2VlcCBpbiBtaW5k
LgooZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSB0eXBlcyBPQkpF
Q1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5cGVzIE9CSkVDVCBi
ZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMgdHlwZSB0byB0aGUg
bW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJzaXZlIGNhbGwgb24gdGhlIHNhbWUg
T0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAgOzsgb2NjdXIgd2hlbiBhIHBhcmVu
dCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIgYW4gb2JqZWN0J3MgdHlwZSBpcwogIDs7IHRo
YXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJlbi4KICAodW5sZXNzIChlcSBvYmplY3QgY2wtLXR5
cGUtb2JqZWN0KQogICAgKGxldCAoKGNsLS10eXBlLW9iamVjdCBvYmplY3QpCiAgICAgICAg
ICAoZm91bmQgKGxpc3QgKGNsLS10eXBlLXBhcmVudHMgKGNsLXR5cGUtb2Ygb2JqZWN0KSkp
KSkKICAgICAgOzsgQ29sbGVjdCBhbGwgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8uCiAgICAg
IChkb2xpc3QgKHR5cGUgY2wtLXR5cGUtbGlzdCkKICAgICAgICAoYW5kIChjbC10eXBlcCAo
Y2wtLWZpbmQtY2xhc3MgdHlwZSkgJ2NsLXR5cGUtY2xhc3MpCiAgICAgICAgICAgICAoY2wt
dHlwZXAgb2JqZWN0IHR5cGUpCiAgICAgICAgICAgICAocHVzaCAoY2wtLXR5cGUtcGFyZW50
cyB0eXBlKSBmb3VuZCkpKQogICAgICAoc2V0cSBmb3VuZCAobWVyZ2Utb3JkZXJlZC1saXN0
cyBmb3VuZCkpCiAgICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUgb2YgdHlwZS4KICAg
ICAgKHdpdGgtbWVtb2l6YXRpb24gKGdldGhhc2ggZm91bmQgY2wtLXR5cGUtdW5pcXVlKQog
ICAgICAgIGZvdW5kKSkpKQoKOzs7IE1ldGhvZCBkaXNwYXRjaGluZwo7OwooY2wtZ2VuZXJp
Yy1kZWZpbmUtZ2VuZXJhbGl6ZXIgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIKICAyMCA7OyAidHlw
ZW9mIiA8ICJjbC10eXBlcy1vZiIgPCAiaGVhZCIgcHJpb3JpdHkKICAobGFtYmRhIChvYmog
JnJlc3QgXykgYChjbC10eXBlcy1vZiAsb2JqKSkKICAobGFtYmRhICh0YWcgJnJlc3QgXykg
KGlmIChjb25zcCB0YWcpIHRhZykpKQoKKGNsLWRlZm1ldGhvZCBjbC1nZW5lcmljLWdlbmVy
YWxpemVycyA6ZXh0cmEgImNsLXR5cGVzLW9mIiAodHlwZSkKICAiU3VwcG9ydCBmb3IgZGlz
cGF0Y2ggb24gdHlwZXMuIgogIChpZiAoY2wtLXR5cGUtcCB0eXBlKQogICAgICAobGlzdCBj
bC0tdHlwZS1nZW5lcmFsaXplcikKICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkpCgo7Ozsg
U29tZSB0ZXN0cwo7OwonKHByb2duCiAgIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC1ieXRlICgm
b3B0aW9uYWwgYml0cykKICAgICAiVW5zaWduZWQgaW50ZWdlci4iCiAgICAgYChpbnRlZ2Vy
IDAgLChpZiAoZXEgYml0cyAnKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAgKGNs
LWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICJVbnNpZ25lZCAxNi1iaXRzIGlu
dGVnZXIuIgogICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgICco
dW5zaWduZWQtYnl0ZSAxNikpCgogICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtOGJpdHMgKCkK
ICAgICAiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuIgogICAgIChkZWNsYXJlIChwYXJlbnRz
IHVuc2lnbmVkLTE2Yml0cykpCiAgICAgJyh1bnNpZ25lZC1ieXRlIDgpKQoKICAgKGNsLXR5
cGVzLW9mIDEwMCkKICAgOzsgKHVuc2lnbmVkLThiaXRzIHVuc2lnbmVkLTE2Yml0cyB1bnNp
Z25lZC1ieXRlIGZpeG51bSkKCiAgIChjbC10eXBlcy1vZiAyNTYpCiAgIDs7ICh1bnNpZ25l
ZC0xNmJpdHMgdW5zaWduZWQtYnl0ZSBmaXhudW0pCgogICAoY2wtdHlwZXMtb2YgbW9zdC1w
b3NpdGl2ZS1maXhudW0pCiAgIDs7ICh1bnNpZ25lZC1ieXRlIGZpeG51bSkKCiAgIChjbC1k
ZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWduZWQtYnl0ZSkpCiAgICAgKGZvcm1hdCAidW5z
aWduZWQiKSkKCiAgIChjbC1kZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWduZWQtMTZiaXRz
KSkKICAgICAoZm9ybWF0ICJ1bnNpZ25lZCAxNmJpdHMgLSBhbHNvICVzIgogICAgICAgICAg
ICAgKGNsLWNhbGwtbmV4dC1tZXRob2QpKSkKCiAgIChjbC1kZWZtZXRob2QgbXktZm9vICgo
X24gdW5zaWduZWQtOGJpdHMpKQogICAgIChmb3JtYXQgInVuc2lnbmVkIDhiaXRzIC0gYWxz
byAlcyIKICAgICAgICAgICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkpCgogICAobXktZm9v
IDEwMCkKICAgOzsgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyB1bnNpZ25lZCIKCiAgIChteS1m
b28gMjU2KQogICA7OyAidW5zaWduZWQgMTZiaXRzIC0gYWxzbyB1bnNpZ25lZCA4Yml0cyAt
IGFsc28gdW5zaWduZWQiCgogICAobXktZm9vIG1vc3QtcG9zaXRpdmUtZml4bnVtKQogICA7
OyAidW5zaWduZWQiCgogICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtMTZiaXRzICgpCiAgICAg
IlVuc2lnbmVkIDE2LWJpdHMgaW50ZWdlci4iCiAgICAgKGRlY2xhcmUgKHBhcmVudHMgdW5z
aWduZWQtOGJpdHMpKQogICAgICcodW5zaWduZWQtYnl0ZSAxNikpCiAgIDs7IEludmFsaWQg
REFHIGVycm9yCgogICkK
--------------PB4Obs9l4nluomYQAxkWHcmP--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 17 Apr 2025 15:28:01 +0000
Resent-Message-ID: <handler.77725.B77725.174490363414362 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174490363414362
(code B ref 77725); Thu, 17 Apr 2025 15:28:01 +0000
Received: (at 77725) by debbugs.gnu.org; 17 Apr 2025 15:27:14 +0000
Received: from localhost ([127.0.0.1]:48132 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5R90-0003jW-45
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 11:27:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17447)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u5R8v-0003iN-F1
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 11:27:10 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BBB984421AA;
Thu, 17 Apr 2025 11:27:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744903622;
bh=g5oVlZSyBTXi8fJMeiLDtiKvJBJZh1fXXW6ry/ln6d0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=fo65d5SFfCS6A1OJdBN7T0EfTpyKmbkb8VAhVgf1p9AsY5sY7eWNPeeEbSrV8fPn9
95baqBPImLGmvxa2xjUN1bvLfUoBzxb2sXVOOumZoOH/+mTjk+0+CB1LOH1hgbYNhf
v+djulpZuvkUZ9H67kSwxelOVA4axNVQYac7nA7ZBJXPzzGouYWC/uxT3U2vwXRkR1
jfcdaWuD0DlFpKFJI6V1P0jYeRxVN8MFJdcnPTlkcH3BGNyF5f6R2yzsQahlQcv/2W
fwR3JfeGozkiyrc4vA957KJovsb2mhjKkS9FHq61GBc7rwmXfFA4oGYphJEgnSGTNl
JQYQRStT2Tkag==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 358AB4420DC;
Thu, 17 Apr 2025 11:27:02 -0400 (EDT)
Received: from pastel (104-195-239-180.cpe.teksavvy.com [104.195.239.180])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 049D8120E98;
Thu, 17 Apr 2025 11:27:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
Message-ID: <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
Date: Thu, 17 Apr 2025 11:27:01 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.024 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> (or (eq (type-of class) 'cl-type-class)
>>> (error "Type in another class: %S" (type-of class))))
>>> (or (listp parents) (setq parents (list parents)))
>>> (if (memq name parents)
>>> (error "Type in parents: %S" parents))
>> Not sure how useful is this test.
>
> I removed testing if parents is a list, this is always true.
> The other test prevents to define a type whose parent is itself.
My comment was specifically about the last 2 lines testing if `name` is
in `parents`. How likely is this error? Wouldn't it be caught by the
DAG test later anyway?
>>> ;; Clear cached value of specializers with NAME.
>>> (if class
>>> (cl--type-reset-specializers name)
>>> ;; Record new type.
>>> (push name cl--type-list))
>> Shouldn't we test `reged` before `push`ing?
> Not sure to understand this point. name needs to be in cl--type-list
> before to call merge-ordered-lists on the DAG.
IIRC if `reged` is non-nil, `name` is already included in
`cl--type-list` so we shouldn't push it again there.
>>> (defmacro cl-type-undefine (name)
>>> "Remove the definitions of type with NAME.
>>> NAME is an unquoted symbol representing a type.
>>> Signal an error if other types inherit from NAME."
>>> `(progn
>>> (cl-check-type ',name (satisfies cl-type-p))
>>> (cl--type-undefine ',name)))
>> We don't have that for other types. I understand it's somewhat
>> dangerous for the other types and not for this one, but I still wonder
>> if we need it.
> I thought it could be useful, for example to cleanup the environment
> when you kind of uninstall a library which defined types. Maybe it
> could help during tests?
I'm not saying it can't be useful, just wondering if it will be.
In either case it doesn't seem like there's a good reason it should be
a `defmacro` rather than a `defun`.
BTW, part of this is handled by `define-symbol-prop` which makes sure
that the `cl-deftype-handler` is automatically removed when you
`unload-feature`. Maybe we should use `define-symbol-prop` instead of
`setf` for the `cl--class` property as well.
>> That doesn't sound right: it works only if there are no types which are
>> overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
>> We may be able to use the `subtype-of` info to skip some types (e.g. we
>> don't need to test the parents, or if we traverse the list in the other
>> direction, we don't need to test FOO if we already saw that the object
>> failed the test for one of FOO's parents), but in general we'll have to
>> check them all: we definitely can't stop at the first successful check.
> Good point. But you lost me regarding possible optimizations :-(
If BAR is declared as a parent of FOO and `cl-types-of` has already
decided that the value *is* of type FOO, then we already know BAR will
be in the output anyway and there's no point testing BAR.
The converse is that if we have already decided that the value is *not*
for type BAR, then it can't be of type FOO either, so there's no point
testing FOO.
This presumes that the declaration that BAR is parent of FOO is
actually correct, of course.
> I returned to the previous version that check all types.
Good.
>>> ;;; Some tests
> [...]
>> I suggest to define something like `multiples-of-2`, `multiples-of-3`,
>> and `multiples-of-4`, so as to test more complex relationships between
>> types (with overlap but not inclusion).
>
> Do you have any examples in mind?
Test that (c-types-of 4) is (multiples-of-4 multiples-of-2 ...)
Test that (c-types-of 6) is (multiples-of-3 multiples-of-2 ...)
Test that (c-types-of 12) is (multiples-of-4 multiples-of-3 multiples-of-2 ...)
This would have failed with your previous code which didn't check
all types.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 17 Apr 2025 23:02:02 +0000
Resent-Message-ID: <handler.77725.B77725.17449308758936 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17449308758936
(code B ref 77725); Thu, 17 Apr 2025 23:02:02 +0000
Received: (at 77725) by debbugs.gnu.org; 17 Apr 2025 23:01:15 +0000
Received: from localhost ([127.0.0.1]:48847 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5YEI-0002JF-9B
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 19:01:14 -0400
Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:56595
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u5YEC-0002I0-7W
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 19:01:08 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 5YE5ufIdhwRVI5YE9uDwpb; Fri, 18 Apr 2025 01:01:02 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744930862;
bh=QwQC5fYxJODpskiwX39brBbsrUHj2TAhRsqeg+l4pDc=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=o7DEfNJD2k8EcsLLPl89Js6MNJfrQsWkAE5A/QTMXGtfQuUGpb+eNs71bAfkOH9wi
9+d85u9QYnop2AbbAdfMryiYGVcTr8zKNx0WXCOYHtbJPvU1yeHTLZ0VPxl2jxmy0z
bcSSTeAbtc03snNBAarJTEKy4Vi7DyXEdefryvxSnPzdEP2dXo0c4eQEcAy5fm59Fg
2KeIQybsFwdOWS0APuU6Q1y5opJ6cX5tJnFKerncwEYDLLRloNLhxbwX/5RgDySMM2
pS6o/W+6ec2WiLsxb8ED2VGlNY4HtXPwttp8rNzsHOx2qEFacILLPrXE4NDbxK/Ngy
Boa92siMfSs5A==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 18 Apr 2025 01:01:02 +0200
X-ME-IP: 90.112.40.65
Message-ID: <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
Date: Fri, 18 Apr 2025 01:00:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-17 17:27, Stefan Monnier wrote:
>>>> (if (memq name parents)
>>>> (error "Type in parents: %S" parents))
>>> Not sure how useful is this test.
>>
>> I removed testing if parents is a list, this is always true.
>> The other test prevents to define a type whose parent is itself.
>
> My comment was specifically about the last 2 lines testing if `name` is
> in `parents`. How likely is this error? Wouldn't it be caught by the
> DAG test later anyway?
In principle your are correct, the cycle should be caught at DAG test.
But it seems it's not the case. I removed the test for `name' in `parents'
and tried these definitions:
(cl-deftype test ()
'number)
(cl-deftype test ()
(declare (parents test))
'number)
Normally, the second definition should be caught by the DAG test, but is
not, and produced wrong definition, with `cl--type-list' equals to
(test test).
It seems the problem is that `merge-ordered-lists' doesn't caught this
case:
(merge-ordered-lists '((test test)))
=> (test test)
I tried the same test with the topologic sort, and it failed as expected:
(gtype--topologic-sort '((test test)))
=> "Invalid graph" error
>
>>>> ;; Clear cached value of specializers with NAME.
>>>> (if class
>>>> (cl--type-reset-specializers name)
>>>> ;; Record new type.
>>>> (push name cl--type-list))
>>> Shouldn't we test `reged` before `push`ing?
>> Not sure to understand this point. name needs to be in cl--type-list
>> before to call merge-ordered-lists on the DAG.
>
> IIRC if `reged` is non-nil, `name` is already included in
> `cl--type-list` so we shouldn't push it again there.
In fact, push is done only if `class' is nil, which is the equivalent
to `reged' non-nil. For clarity, I changed to test with `reged'
(renamed `recorded' new versions).
>>>> (defmacro cl-type-undefine (name)
>>>> "Remove the definitions of type with NAME.
>>>> NAME is an unquoted symbol representing a type.
>>>> Signal an error if other types inherit from NAME."
>>>> `(progn
>>>> (cl-check-type ',name (satisfies cl-type-p))
>>>> (cl--type-undefine ',name)))
>>> We don't have that for other types. I understand it's somewhat
>>> dangerous for the other types and not for this one, but I still wonder
>>> if we need it.
>> I thought it could be useful, for example to cleanup the environment
>> when you kind of uninstall a library which defined types. Maybe it
>> could help during tests?
>
> I'm not saying it can't be useful, just wondering if it will be.
> In either case it doesn't seem like there's a good reason it should be
> a `defmacro` rather than a `defun`.
>
> BTW, part of this is handled by `define-symbol-prop` which makes sure
> that the `cl-deftype-handler` is automatically removed when you
> `unload-feature`. Maybe we should use `define-symbol-prop` instead of
> `setf` for the `cl--class` property as well.
This is good to know. For now, I only kept the function `cl--type-undefine',
in case we need it to cleanup things while testing. We can remove it later
if not useful.
>>> That doesn't sound right: it works only if there are no types which are
>>> overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
>>> We may be able to use the `subtype-of` info to skip some types (e.g. we
>>> don't need to test the parents, or if we traverse the list in the other
>>> direction, we don't need to test FOO if we already saw that the object
>>> failed the test for one of FOO's parents), but in general we'll have to
>>> check them all: we definitely can't stop at the first successful check.
>> Good point. But you lost me regarding possible optimizations :-(
>
> If BAR is declared as a parent of FOO and `cl-types-of` has already
> decided that the value *is* of type FOO, then we already know BAR will
> be in the output anyway and there's no point testing BAR.
This looks like what I did in my previous version. When FOO matched,
I put FOO and its parents in the result. My mistake was stopping there
instead of continuing to the end of the list!
> The converse is that if we have already decided that the value is *not*
> for type BAR, then it can't be of type FOO either, so there's no point
> testing FOO.
Wouldn't this involve calculating the parents of all the types traversed,
instead of just the matching ones? If so, wouldn't we risk losing on one
side what we gain on the other?
>>>> ;;; Some tests
>> [...]
>>> I suggest to define something like `multiples-of-2`, `multiples-of-3`,
>>> and `multiples-of-4`, so as to test more complex relationships between
>>> types (with overlap but not inclusion).
>>
>> Do you have any examples in mind?
>
> Test that (c-types-of 4) is (multiples-of-4 multiples-of-2 ...)
> Test that (c-types-of 6) is (multiples-of-3 multiples-of-2 ...)
> Test that (c-types-of 12) is (multiples-of-4 multiples-of-3 multiples-of-2 ...)
>
> This would have failed with your previous code which didn't check
> all types.
Thank you, I'll give it a try.
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 18 Apr 2025 03:44:05 +0000
Resent-Message-ID: <handler.77725.B77725.174494778810096 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174494778810096
(code B ref 77725); Fri, 18 Apr 2025 03:44:05 +0000
Received: (at 77725) by debbugs.gnu.org; 18 Apr 2025 03:43:08 +0000
Received: from localhost ([127.0.0.1]:49147 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5cd7-0002cb-M5
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 23:43:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18428)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u5cd1-0002b1-9G
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 23:43:02 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 28A5B807BC;
Thu, 17 Apr 2025 23:42:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744947769;
bh=P3wiOWcF2mGAaUjT10k7HZL3oGtQk+EImI8/mK8aVZU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=iOtoVTe32c2KE3Lahp76QvzOuy816UV6OZhf0oGSVz0gQVZT57/dGSH22RPuHFviO
KVOWknYwNb5ZT2CkR6gthlyUUWL7gSTWRGLuGyc5Bd6/Ix9O1JE1T0QafnIqRu0MKR
piKCE3fVBj77zaftC7vS/0Pv7QvasTYl8KdXfzbm2kx7b5ckO9KvZJ6sChxjinbPQy
XGpPM9vhd/lG+WI+7dZKypB1Ia8dWQ68lyGhraQ7Ti7Pu3JBUEx0vuk8QrRiwdSKkA
Xez9tOGivbgOvuT8Aw3SuSJu8FI1acgHZCoo+jYmyDB/IbiVjjsawXNcSTtRqscH3v
ZkmoUzexPw1oQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 539E7806BF;
Thu, 17 Apr 2025 23:42:49 -0400 (EDT)
Received: from pastel (104-195-239-180.cpe.teksavvy.com [104.195.239.180])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 26D63120713;
Thu, 17 Apr 2025 23:42:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
Message-ID: <jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
Date: Thu, 17 Apr 2025 23:42:48 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.053 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> (merge-ordered-lists '((test test)))
> => (test test)
Ah, right, `merge-ordered-lists` presumes the arg lists are already sane.
>> The converse is that if we have already decided that the value is *not*
>> for type BAR, then it can't be of type FOO either, so there's no point
>> testing FOO.
> Wouldn't this involve calculating the parents of all the types traversed,
> instead of just the matching ones?
I wasn't describing an algorithm, just a principle that can be used
within an algorithm. Depending on the algorithm you use it can be used
in different ways. With your current loop, I don't think you can make
much use of it.
But I think what we could do fairly easily is the following:
- based on the PARENTS declaration, create a map from builtin-type to
the set of cl-types that have that builtin-type among their parents.
That presumes some PARENTS include some builtin-types, obviously
otherwise the map will be trivial with all cl-types associated with
the `t` "dummy parent".
[ We could even go crazy and try and guess PARENTS when not provided,
by analyzing the type's definition. ]
- in `cl-types-of` start by calling `cl-type-of`, then use the map to
find which cl-types may need to be checked.
But let's keep this for later.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 18 Apr 2025 15:08:03 +0000
Resent-Message-ID: <handler.77725.B77725.1744988840639 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.1744988840639
(code B ref 77725); Fri, 18 Apr 2025 15:08:03 +0000
Received: (at 77725) by debbugs.gnu.org; 18 Apr 2025 15:07:20 +0000
Received: from localhost ([127.0.0.1]:52460 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5nJC-00009O-SY
for submit <at> debbugs.gnu.org; Fri, 18 Apr 2025 11:07:19 -0400
Received: from [80.12.242.23] (port=42707 helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u5nIt-0007yS-FT
for 77725 <at> debbugs.gnu.org; Fri, 18 Apr 2025 11:07:10 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 5nF4uuSNM4rbB5nF7uiQrQ; Fri, 18 Apr 2025 17:03:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744988584;
bh=HkgjYspVaLkQfXp74jCtnjW76YTINsxJlnVmE/eUXxI=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=LB4FVUqQ6y2ifapK8EMcJGoPVrjkbwQFh7wqWJJQoU2J8LN0yaYm0p2S9dUXOOjvF
28T+aSymDPA7aKXgjujl0rw5/GARSwntZPZc1elGmpVJyn7oJkiO3L/UVhYptkid0U
sg5YRW1Z5rENVdogVJl5PH75YQz4KztIUzvgIlpQbcM9HHDHFVo3vp34tpjCtDylMg
o4Enn2/qaNqtkrDmrMP3IdFb7Sj0Nw07sqO14DwlKJFefzNCFwGqrRnKpeYasm/CnW
3kn/1q4kazWxWjB7Hx76e0rp94b8IGPlIZIRSYax25l+MsxkqFpZwPktQTtjil5XJK
Lc3lbICXj42Hw==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 18 Apr 2025 17:03:04 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------oQNclki4E7GToXoSUh4I3NAy"
Message-ID: <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
Date: Fri, 18 Apr 2025 17:02:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hi Stefan,
>> (merge-ordered-lists '((test test))) >> => (test
test) > > Ah, right, `merge-ordered-lists` presumes the arg lists are already
sane. > So, I kept the test to ensure `name' is not in `parents'.
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[80.12.242.23 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[80.12.242.23 listed in sa-trusted.bondedsender.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [80.12.242.23 listed in list.dnswl.org]
0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror)
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (da_vid[at]orange.fr)
0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror)
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
0.0 SPOOFED_FREEMAIL_NO_RDNS From SPOOFED_FREEMAIL and no rDNS
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)
This is a multi-part message in MIME format.
--------------oQNclki4E7GToXoSUh4I3NAy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Stefan,
>> (merge-ordered-lists '((test test)))
>> => (test test)
>
> Ah, right, `merge-ordered-lists` presumes the arg lists are already sane.
>
So, I kept the test to ensure `name' is not in `parents'.
>>> The converse is that if we have already decided that the value is *not*
>>> for type BAR, then it can't be of type FOO either, so there's no point
>>> testing FOO.
>> Wouldn't this involve calculating the parents of all the types traversed,
>> instead of just the matching ones?
>
> I wasn't describing an algorithm, just a principle that can be used
> within an algorithm. Depending on the algorithm you use it can be used
> in different ways. With your current loop, I don't think you can make
> much use of it.
>
> But I think what we could do fairly easily is the following:
>
> - based on the PARENTS declaration, create a map from builtin-type to
> the set of cl-types that have that builtin-type among their parents.
> That presumes some PARENTS include some builtin-types, obviously
> otherwise the map will be trivial with all cl-types associated with
> the `t` "dummy parent".
> [ We could even go crazy and try and guess PARENTS when not provided,
> by analyzing the type's definition. ]
> - in `cl-types-of` start by calling `cl-type-of`, then use the map to
> find which cl-types may need to be checked.
>
> But let's keep this for later.
I was thinking about the exact same idea not long ago :-) I totally
agree with your analysis. I noted this point in a FIXME.
Please, find attached a new version of cl-types.el:
- I've divided the code more logically between the `cl-deftype2' macro
and the `cl--type-generalize' function.
- In `cl-types-of', I implemented the idea of not testing a type
already selected as a parent of a type already selected :-)
- I tried to add some comments to the not so obvious code.
I also wrote a first try at a test file, cl-types-tests.el, also
attached:
- It includes your proposed tests with multiples-of...
All tests pass for me :-)
Please let me know if something is not correct, need more work, etc.
Regarding a possible merge in cl-lib, should cl-types.el be copied at
the end of cl-lib, after cl-macs is loaded? If I correctly understand
the logic of loading these libs ;-)
Thank you!
David
--------------oQNclki4E7GToXoSUh4I3NAy
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types-tests.el"
Content-Disposition: attachment; filename="cl-types-tests.el"
Content-Transfer-Encoding: base64
Ozs7IFRlc3QgYGNsLXR5cGVkZWYnIC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQo7Owoo
cmVxdWlyZSAnZXJ0KQoocmVxdWlyZSAnY2wtdHlwZXMpCgooZXJ0LWRlZnRlc3QgY2wtdHlw
ZXMtdGVzdC0xICgpCiAgIlRlc3QgdHlwZXMgZGVmaW5pdGlvbiBhbmQgY2wtdHlwZXMtb2Yu
IgogIAogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAgKGV2YWwKICAgICAnKGNsLWRlZnR5
cGUyIG11bHRpcGxlcy1vZiAoJm9wdGlvbmFsIG0pCiAgICAgICAgKGxldCAoKG11bHRpcGxl
cCAoaWYgKGVxIG0gJyopCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIydpZ25vcmUK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAobikgKD0gMCAoJSBuIG0pKSkp
KSkgIAogICAgICAgICAgYChhbmQgaW50ZWdlciAoc2F0aXNmaWVzICxtdWx0aXBsZXApKSkp
CiAgICAgbGV4aWNhbC1iaW5kaW5nCiAgICAgKSkpCiAgCiAgKHNob3VsZAogICAoZnVuY3Rp
b25wCiAgICAoZXZhbAogICAgICcoY2wtZGVmdHlwZTIgbXVsdGlwbGVzLW9mLTIgKCkKICAg
ICAgICAnKG11bHRpcGxlcy1vZiAyKSkKICAgICBsZXhpY2FsLWJpbmRpbmcKICAgICApKSkK
ICAKICAoc2hvdWxkCiAgIChmdW5jdGlvbnAKICAgIChldmFsCiAgICAgJyhjbC1kZWZ0eXBl
MiBtdWx0aXBsZXMtb2YtMyAoKQogICAgICAgICcobXVsdGlwbGVzLW9mIDMpKQogICAgIGxl
eGljYWwtYmluZGluZwogICAgICkpKQogIAogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAg
KGV2YWwKICAgICAnKGNsLWRlZnR5cGUyIG11bHRpcGxlcy1vZi00ICgpCiAgICAgICAgKGRl
Y2xhcmUgKHBhcmVudHMgbXVsdGlwbGVzLW9mLTIpKQogICAgICAgICcoYW5kIG11bHRpcGxl
cy1vZi0yIChtdWx0aXBsZXMtb2YgNCkpKQogICAgIGxleGljYWwtYmluZGluZwogICAgICkp
KQoKICA7OyBUZXN0IHRoYXQgKGNsLXR5cGVzLW9mIDQpIGlzIChtdWx0aXBsZXMtb2YtNCBt
dWx0aXBsZXMtb2YtMiAuLi4pCiAgOzsgVGVzdCB0aGF0IChjbC10eXBlcy1vZiA2KSBpcyAo
bXVsdGlwbGVzLW9mLTMgbXVsdGlwbGVzLW9mLTIgLi4uKQogIDs7IFRlc3QgdGhhdCAoY2wt
dHlwZXMtb2YgMTIpIGlzIChtdWx0aXBsZXMtb2YtNCBtdWx0aXBsZXMtb2YtMyBtdWx0aXBs
ZXMtb2YtMiAuLi4pCiAgKHNob3VsZAogICAoZXF1YWwKICAgIChjbC10eXBlcy1vZiAyKQog
ICAgJyggbXVsdGlwbGVzLW9mLTIgZml4bnVtIGludGVnZXIgbnVtYmVyIGludGVnZXItb3It
bWFya2VyCiAgICAgICBudW1iZXItb3ItbWFya2VyIGF0b20gdCkKICAgICkpCgogIChzaG91
bGQKICAgKGVxdWFsCiAgICAoY2wtdHlwZXMtb2YgNCkKICAgICcoIG11bHRpcGxlcy1vZi00
IG11bHRpcGxlcy1vZi0yIGZpeG51bSBpbnRlZ2VyIG51bWJlcgogICAgICAgaW50ZWdlci1v
ci1tYXJrZXIgbnVtYmVyLW9yLW1hcmtlciBhdG9tIHQpCiAgICApKQoKICAoc2hvdWxkCiAg
IChlcXVhbAogICAgKGNsLXR5cGVzLW9mIDYpCiAgICAnKCBtdWx0aXBsZXMtb2YtMyBtdWx0
aXBsZXMtb2YtMiBmaXhudW0gaW50ZWdlciBudW1iZXIKICAgICAgIGludGVnZXItb3ItbWFy
a2VyIG51bWJlci1vci1tYXJrZXIgYXRvbSB0KQogICAgKSkKCiAgKHNob3VsZAogICAoZXF1
YWwKICAgIChjbC10eXBlcy1vZiAxMikKICAgICcoIG11bHRpcGxlcy1vZi0zIG11bHRpcGxl
cy1vZi00IG11bHRpcGxlcy1vZi0yIGZpeG51bSBpbnRlZ2VyCiAgICAgICBudW1iZXIgaW50
ZWdlci1vci1tYXJrZXIgbnVtYmVyLW9yLW1hcmtlciBhdG9tIHQpCiAgICApKQoKICAoc2hv
dWxkCiAgIChlcXVhbAogICAgKGNsLXR5cGVzLW9mIDUpCiAgICAnKGZpeG51bSBpbnRlZ2Vy
IG51bWJlciBpbnRlZ2VyLW9yLW1hcmtlciBudW1iZXItb3ItbWFya2VyIGF0b20gdCkKICAg
ICkpCgogIDs7IENsZWFudXAKICAobWFwYyAjJ2NsLS10eXBlLXVuZGVmaW5lIGNsLS10eXBl
LWxpc3QpCgogICkKCihlcnQtZGVmdGVzdCBjbC10eXBlcy10ZXN0LTIgKCkKICAiVGVzdCB0
eXBlcyBkZWZpbml0aW9uIGFuZCBkaXNwYXRjaC4iCgogIChzaG91bGQKICAgKGZ1bmN0aW9u
cAogICAgKGV2YWwKICAgICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25h
bCBiaXRzKQogICAgICAgICJVbnNpZ25lZCBpbnRlZ2VyLiIKICAgICAgICBgKGludGVnZXIg
MCAsKGlmIChlcSBiaXRzICcqKSBiaXRzICgxLSAoYXNoIDEgYml0cykpKSkpCiAgICAgbGV4
aWNhbC1iaW5kaW5nCiAgICAgKSkpCgogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAgKGV2
YWwKICAgICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICAgICJVbnNp
Z25lZCAxNi1iaXRzIGludGVnZXIuIgogICAgICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2ln
bmVkLWJ5dGUpKQogICAgICAgICcodW5zaWduZWQtYnl0ZSAxNikpCiAgICAgbGV4aWNhbC1i
aW5kaW5nCiAgICAgKSkpCgogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAgKGV2YWwKICAg
ICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLThiaXRzICgpCiAgICAgICAgIlVuc2lnbmVkIDgt
Yml0cyBpbnRlZ2VyLiIKICAgICAgICAoZGVjbGFyZSAocGFyZW50cyB1bnNpZ25lZC0xNmJp
dHMpKQogICAgICAgICcodW5zaWduZWQtYnl0ZSA4KSkKICAgICBsZXhpY2FsLWJpbmRpbmcK
ICAgICApKSkKCiAgOzsgSW52YWxpZCBEQUcgZXJyb3IKICAoc2hvdWxkLWVycm9yCiAgIChl
dmFsCiAgICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICAgIlVuc2ln
bmVkIDE2LWJpdHMgaW50ZWdlci4iCiAgICAgICAoZGVjbGFyZSAocGFyZW50cyB1bnNpZ25l
ZC04Yml0cykpCiAgICAgICAnKHVuc2lnbmVkLWJ5dGUgMTYpKQogICAgbGV4aWNhbC1iaW5k
aW5nCiAgICApKQoKICAoZXZhbAogICAnKGNsLWRlZm1ldGhvZCBteS1mb28gKChfbiB1bnNp
Z25lZC1ieXRlKSkKICAgICAgKGZvcm1hdCAidW5zaWduZWQiKSkKICAgbGV4aWNhbC1iaW5k
aW5nCiAgICkKCiAgKGV2YWwKICAgJyhjbC1kZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWdu
ZWQtMTZiaXRzKSkKICAgICAgKGZvcm1hdCAidW5zaWduZWQgMTZiaXRzIC0gYWxzbyAlcyIK
ICAgICAgICAgICAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQogICBsZXhpY2FsLWJpbmRp
bmcKICAgKQoKICAoZXZhbAogICAnKGNsLWRlZm1ldGhvZCBteS1mb28gKChfbiB1bnNpZ25l
ZC04Yml0cykpCiAgICAgIChmb3JtYXQgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyAlcyIKICAg
ICAgICAgICAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQogICBsZXhpY2FsLWJpbmRpbmcK
ICAgKQogIAogIChzaG91bGQKICAgKGVxdWFsCiAgICAobXktZm9vIDEwMCkKICAgICJ1bnNp
Z25lZCA4Yml0cyAtIGFsc28gdW5zaWduZWQgMTZiaXRzIC0gYWxzbyB1bnNpZ25lZCIKICAg
ICkpCgogIChzaG91bGQKICAgKGVxdWFsCiAgICAobXktZm9vIDI1NikKICAgICJ1bnNpZ25l
ZCAxNmJpdHMgLSBhbHNvIHVuc2lnbmVkIgogICAgKSkKCiAgKHNob3VsZAogICAoZXF1YWwK
ICAgIChteS1mb28gbW9zdC1wb3NpdGl2ZS1maXhudW0pCiAgICAidW5zaWduZWQiCiAgICAp
KQogIAogIDs7IENsZWFudXAKICAobWFwYyAjJ2NsLS10eXBlLXVuZGVmaW5lIGNsLS10eXBl
LWxpc3QpCiAgKQoKKHByb3ZpZGUgJ2NsLXR5cGVzLXRlc3RzKQoKOzs7IGNsLXR5cGVzLXRl
c3RzLmVsIGVuZHMgaGVyZQo=
--------------oQNclki4E7GToXoSUh4I3NAy
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl
biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCihldmFsLXdoZW4tY29t
cGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5kLWNsYXNzLgoKOzsgRXh0
ZW5kIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgZGF0YSB0eXBlcyB3aGljaCBhcmUgYWxzbyB2
YWxpZAo7OyBhcmd1bWVudCB0eXBlcyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlv
biBtZXRob2RzIChzZWUgYWxzbwo7OyA8aHR0cHM6Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1
Z3JlcG9ydC5jZ2k/YnVnPTc3NzI1PikuCjs7Cjs7IFRoZSBtYWluIGVudHJ5IHBvaW50cyBh
cmU6Cjs7Cjs7IC0gYGNsLWRlZnR5cGUnLCB0aGF0IGRlZmluZXMgbmV3IGRhdGEgdHlwZXMu
Cjs7Cjs7IC0gYGNsLXR5cGVzLW9mJywgdGhhdCByZXR1cm5zIHRoZSB0eXBlcyBhbiBvYmpl
Y3QgYmVsb25ncyB0by4KCihkZWZ2YXIgY2wtLXR5cGUtbGlzdCBuaWwKICAiTGlzdCBvZiBk
ZWZpbmVkIHR5cGVzIHRvIGxvb2t1cCBmb3IgbWV0aG9kIGRpc3BhdGNoaW5nLiIpCgo7OyBG
SVhNRTogVGhlIGBjbC1kZWZ0eXBlLWhhbmRsZXInIHByb3BlcnR5IHNob3VsZCBhcmd1YWJs
eSBiZSB0dXJuZWQKOzsgaW50byBhIGZpZWxkIG9mIHRoaXMgc3RydWN0IChidXQgaXQgaGFz
IHBlcmZvcm1hbmNlIGFuZAo7OyBjb21wYXRpYmlsaXR5IGltcGxpY2F0aW9ucywgc28gbGV0
J3Mgbm90IG1ha2UgdGhhdCBjaGFuZ2UgZm9yIG5vdykuCihjbC1kZWZzdHJ1Y3QKICAgIChj
bC10eXBlLWNsYXNzCiAgICAgKDppbmNsdWRlIGNsLS1jbGFzcykKICAgICAoOm5vaW5saW5l
IHQpCiAgICAgKDpjb25zdHJ1Y3RvciBuaWwpCiAgICAgKDpjb25zdHJ1Y3RvciBjbC0tdHlw
ZS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAgICAobmFtZQogICAgICAgICAgICAgICAg
ICAgIGRvY3N0cmluZwogICAgICAgICAgICAgICAgICAgIHBhcmVudC10eXBlcwogICAgICAg
ICAgICAgICAgICAgICZhdXggKHBhcmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAo
bWFwY2FyCiAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKHR5cGUpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKG9yIChjbC0tZmluZC1jbGFzcyB0eXBlKQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIlVua25vd24gdHlwZTogJVMi
IHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5cGVzKSkpKQog
ICAgICg6Y29waWVyIG5pbCkpCiAgIlR5cGUgZGVzY3JpcHRvcnMgZm9yIHR5cGVzIGRlZmlu
ZWQgYnkgYGNsLWRlZnR5cGUnLiIpCgooZGVmdW4gY2wtLXR5cGUtcCAob2JqZWN0KQogICJS
ZXR1cm4gbm9uLW5pbCBpZiBPQkpFQ1QgaXMgYSB1c2VkIGRlZmluZWQgdHlwZS4KVGhhdCBp
cywgYSB0eXBlIG9mIGNsYXNzIGBjbC10eXBlLWNsYXNzJy4iCiAgKGFuZCAoc3ltYm9scCBv
YmplY3QpCiAgICAgICAoY2wtdHlwZXAgKGNsLS1maW5kLWNsYXNzIG9iamVjdCkgJ2NsLXR5
cGUtY2xhc3MpKSkKCihkZWZtYWNybyBjbC0tdHlwZS1wYXJlbnRzIChuYW1lKQogICJHZXQg
cGFyZW50cyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCByZXByZXNlbnRp
bmcgYSB0eXBlLiIKICBgKGNsLS1jbGFzcy1hbGxwYXJlbnRzIChjbC0tZmluZC1jbGFzcyAs
bmFtZSkpKQoKKGRlZnVuIGNsLS10eXBlLWNoaWxkcmVuIChuYW1lKQogICJHZXQgY2hpbGRy
ZW4gb2YgdGhlIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGlu
ZyBhIHR5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgogIChj
bC1jaGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAobGV0IChjaGls
ZHJlbikKICAgIChkb2xpc3QgKGVsdCBjbC0tdHlwZS1saXN0KQogICAgICAob3IgKGVxIG5h
bWUgZWx0KQogICAgICAgICAgKGlmIChtZW1xIG5hbWUgKGNsLS10eXBlLXBhcmVudHMgZWx0
KSkKICAgICAgICAgICAgICAocHVzaCBlbHQgY2hpbGRyZW4pKSkpCiAgICBjaGlsZHJlbikp
CgooZGVmdW4gY2wtLXR5cGUtZGFnICgpCiAgIlJldHVybiBhIERBRyBmcm9tIHRoZSBsaXN0
IG9mIGRlZmluZWQgdHlwZXMuIgogIChtYXBjYXIgKGxhbWJkYSAodHlwZSkgKGNsLS1jbGFz
cy1hbGxwYXJlbnRzIChjbC0tZmluZC1jbGFzcyB0eXBlKSkpCiAgICAgICAgICBjbC0tdHlw
ZS1saXN0KSkKCjs7IEtlZXAgaXQgZm9yIG5vdywgZm9yIHRlc3RpbmcuCihkZWZ1biBjbC0t
dHlwZS11bmRlZmluZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0aW9ucyBvZiB0eXBl
IHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEg
dHlwZS4KU2lnbmFsIGFuIGVycm9yIGlmIG90aGVyIHR5cGVzIGluaGVyaXQgZnJvbSBOQU1F
LiIKICAoZGVjbGFyZS1mdW5jdGlvbiBjbC1yZW1wcm9wICJjbC1leHRyYSIgKHN5bWJvbCBw
cm9wbmFtZSkpCiAgKGNsLWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXAp
KQogICh3aGVuLWxldCogKChjaGlsZHJlbiAoYW5kIChjbC0tdHlwZS1wIG5hbWUpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKGNsLS10eXBlLWNoaWxkcmVuIG5hbWUpKSkpCiAg
ICAoZXJyb3IgIlR5cGUgaGFzIGNoaWxkcmVuOiAlUyIgY2hpbGRyZW4pKQogIChjbC1yZW1w
cm9wIG5hbWUgJ2NsLS1jbGFzcykKICAoY2wtcmVtcHJvcCBuYW1lICdjbC1kZWZ0eXBlLWhh
bmRsZXIpCiAgKHNldHEgY2wtLXR5cGUtbGlzdCAoZGVscSBuYW1lIGNsLS10eXBlLWxpc3Qp
KSkKCihkZWZ1biBjbC0tdHlwZS1nZW5lcmFsaXplIChuYW1lIHBhcmVudHMgJm9wdGlvbmFs
IGRvY3N0cmluZykKICAiR2VuZXJhbGl6ZSB0eXBlIHdpdGggTkFNRSBmb3IgbWV0aG9kIGRp
c3BhdGNoaW5nLgpQQVJFTlRTIGlzIGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlw
ZSBvZiwgb3IgbmlsLgpET0NTVFJJTkcgaXMgYW4gb3B0aW9uYWwgZG9jdW1lbnRhdGlvbiBz
dHJpbmcuIgogIChsZXQgKChvbGR0bGlzdCAoY29weS1zZXF1ZW5jZSBjbC0tdHlwZS1saXN0
KSkKICAgICAgICAob2xkcGxpc3QgKGNvcHktc2VxdWVuY2UgKHN5bWJvbC1wbGlzdCBuYW1l
KSkpKQogICAgKGNvbmRpdGlvbi1jYXNlIGVycgogICAgICAgIChsZXQqICgoY2xhc3MgKGNs
LS1maW5kLWNsYXNzIG5hbWUpKQogICAgICAgICAgICAgICAocmVjb3JkZWQgKG1lbXEgbmFt
ZSBjbC0tdHlwZS1saXN0KSkpCiAgICAgICAgICAoaWYgKG51bGwgY2xhc3MpCiAgICAgICAg
ICAgICAgKG9yIChudWxsIHJlY29yZGVkKQogICAgICAgICAgICAgICAgICAoZXJyb3IgIlR5
cGUgZ2VuZXJhbGl6ZWQsIGJ1dCBkb2Vzbid0IGV4aXN0IikpCiAgICAgICAgICAgIChvciBy
ZWNvcmRlZCAoZXJyb3IgIlR5cGUgZXhpc3RzLCBidXQgbm90IGdlbmVyYWxpemVkIikpCiAg
ICAgICAgICAgIChvciAoY2wtdHlwZXAgY2xhc3MgJ2NsLXR5cGUtY2xhc3MpCiAgICAgICAg
ICAgICAgICAoZXJyb3IgIlR5cGUgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNs
YXNzKSkpKQogICAgICAgICAgKGlmIChtZW1xIG5hbWUgcGFyZW50cykKICAgICAgICAgICAg
ICAoZXJyb3IgIlR5cGUgaW4gcGFyZW50czogJVMiIHBhcmVudHMpKQogICAgICAgICAgOzsg
U2V0dXAgYSB0eXBlIGRlc2NyaXB0b3IgZm9yIE5BTUUuCiAgICAgICAgICAoc2V0ZiAoY2wt
LWZpbmQtY2xhc3MgbmFtZSkKICAgICAgICAgICAgICAgIChjbC0tdHlwZS1jbGFzcy1tYWtl
IG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKQogICAgICAgICAgOzsgUmVjb3JkIG5ldyB0eXBl
IG5vdyB0byBpbmNsdWRlIGl0cyBkZXBlbmRlbmN5IGluIHRoZSBEQUcuCiAgICAgICAgICAo
b3IgcmVjb3JkZWQgKHB1c2ggbmFtZSBjbC0tdHlwZS1saXN0KSkKICAgICAgICAgIDs7IGBj
bC10eXBlcy1vZicgaXRlcmF0ZXMgdGhyb3VnaCBhbGwga25vd24gdHlwZXMgdG8gY29sbGVj
dAogICAgICAgICAgOzsgYWxsIHRob3NlIGFuIG9iamVjdCBiZWxvbmdzIHRvLCBzb3J0ZWQg
ZnJvbSB0aGUgbW9zdAogICAgICAgICAgOzsgc3BlY2lmaWMgdHlwZSB0byB0aGUgbW9yZSBn
ZW5lcmFsIHR5cGUuICBTbywga2VlcCB0aGUKICAgICAgICAgIDs7IGdsb2JhbCBsaXN0IGlu
IHRoaXMgb3JkZXIuCiAgICAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0CiAgICAgICAgICAg
ICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAgICAgICAgIChjbC0tdHlwZS1k
YWcpCiAgICAgICAgICAgICAgICAgKGxhbWJkYSAoXykgKGVycm9yICJJbnZhbGlkIGRlcGVu
ZGVuY3kgZ3JhcGgiKSkpKSkKICAgICAgKGVycm9yCiAgICAgICA7OyBPbiBlcnJvciByZXN0
b3JlIHByZXZpb3VzIGRhdGEuCiAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0IG9sZHRsaXN0
KQogICAgICAgKHNldGYgKHN5bWJvbC1wbGlzdCBuYW1lKSBvbGRwbGlzdCkKICAgICAgIChl
cnJvciAoZm9ybWF0ICJEZWZpbmUgJVMgZmFpbGVkOiAlcyIKICAgICAgICAgICAgICAgICAg
ICAgIG5hbWUgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikpKSkpKSkKCjs7OyMjI2F1dG9s
b2FkCihkZWZtYWNybyBjbC1kZWZ0eXBlMiAobmFtZSBhcmdsaXN0ICZyZXN0IGJvZHkpCiAg
IkRlZmluZSBOQU1FIGFzIGEgbmV3IGRhdGEgdHlwZS4KVGhlIHR5cGUgTkFNRSBjYW4gdGhl
biBiZSB1c2VkIGluIGBjbC10eXBlY2FzZScsIGBjbC1jaGVjay10eXBlJywgZXRjLAphbmQg
YXMgYXJndW1lbnQgdHlwZSBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbiBtZXRo
b2RzLgoKQVJHTElTVCBpcyBhIENvbW1vbiBMaXNwIGFyZ3VtZW50IGxpc3Qgb2YgdGhlIHNv
cnQgYWNjZXB0ZWQgYnkKYGNsLWRlZm1hY3JvJy4gIEJPRFkgZm9ybXMgYXJlIGV2YWx1YXRl
ZCBhbmQgc2hvdWxkIHJldHVybiBhIHR5cGUKc3BlY2lmaWVyIHRoYXQgaXMgZXF1aXZhbGVu
dCB0byB0aGUgdHlwZSAoc2VlIHRoZSBJbmZvIG5vZGUgYChjbCkgVHlwZQpQcmVkaWNhdGVz
JyBpbiB0aGUgR05VIEVtYWNzIENvbW1vbiBMaXNwIEVtdWxhdGlvbiBtYW51YWwpLgoKSWYg
dGhlcmUgaXMgYSBgZGVjbGFyZScgZm9ybSBpbiBCT0RZLCB0aGUgc3BlYyAocGFyZW50cyBQ
QVJFTlRTKSBpcwpyZWNvZ25pemVkIHRvIHNwZWNpZnkgYSBsaXN0IG9mIHR5cGVzIE5BTUUg
aXMgYSBzdWJ0eXBlIG9mLiAgRm9yCmluc3RhbmNlOgoKICAoY2wtZGVmdHlwZTIgdW5zaWdu
ZWQtYnl0ZSAoJm9wdGlvbmFsIGJpdHMpCiAgICBcIlVuc2lnbmVkIGludGVnZXIuXCIKICAg
IChsaXN0IFxcPSdpbnRlZ2VyIDAgKGlmIChlcSBiaXRzIFxcPScqKSBiaXRzICgxLSAoYXNo
IDEgYml0cykpKSkpCgogIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC04Yml0cyAoKQogICAgXCJV
bnNpZ25lZCA4LWJpdHMgaW50ZWdlci5cIgogICAgKGRlY2xhcmUgKHBhcmVudHMgdW5zaWdu
ZWQtYnl0ZSkpCiAgICBcXD0nKHVuc2lnbmVkLWJ5dGUgOCkpCgpUaGUgbGlzdCBvZiBQQVJF
TlRTIHR5cGVzIGRldGVybWluZXMgdGhlIG9yZGVyIG9mIG1ldGhvZHMgaW52b2NhdGlvbiwK
YW5kIG1pc3NpbmcgUEFSRU5UUyBtYXkgY2F1c2UgaW5jb3JyZWN0IG9yZGVyaW5nIG9mIG1l
dGhvZHMsIHdoaWxlCmV4dHJhbmVvdXMgUEFSRU5UUyBtYXkgY2F1c2UgdXNlIG9mIGV4dHJh
bmVvdXMgbWV0aG9kcy4iCiAgKGRlY2xhcmUgKGRlYnVnIGNsLWRlZm1hY3JvKSAoZG9jLXN0
cmluZyAzKSAoaW5kZW50IDIpKQogIChwY2FzZS1sZXQqCiAgICAgICgoYCgsZGVjbHMgLiAs
Zm9ybXMpIChtYWNyb2V4cC1wYXJzZS1ib2R5IGJvZHkpKQogICAgICAgKGRvY3N0cmluZyAo
aWYgKHN0cmluZ3AgKGNhciBkZWNscykpCiAgICAgICAgICAgICAgICAgICAgICAoY2FyIGRl
Y2xzKQogICAgICAgICAgICAgICAgICAgIChjYWRyIChhc3NxIDpkb2N1bWVudGF0aW9uIGRl
Y2xzKSkpKQogICAgICAgKHBhcmVudHMgKGNkciAoYXNzcSAncGFyZW50cyAoY2RyIChhc3Nx
ICdkZWNsYXJlIGRlY2xzKSkpKSkpCiAgICAoYW5kIHBhcmVudHMgYXJnbGlzdAogICAgICAg
ICAoZXJyb3IgIlBhcmVudHMgc3BlY2lmaWVkLCBidXQgYXJnbGlzdCBub3QgZW1wdHkiKSkK
ICAgIChpZiBkb2NzdHJpbmcgKHNldHEgZm9ybXMgKGNvbnMgZG9jc3RyaW5nIGZvcm1zKSkp
CiAgICBgKGNsLWV2YWwtd2hlbiAoY29tcGlsZSBsb2FkIGV2YWwpCiAgICAgICAoY2wtLXR5
cGUtZ2VuZXJhbGl6ZSAnLG5hbWUgJyxwYXJlbnRzICxkb2NzdHJpbmcpCiAgICAgICAoZGVm
aW5lLXN5bWJvbC1wcm9wICcsbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChjbC1mdW5jdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGxhbWJkYSAoJmNsLWRlZnMgKCcqKSAsQGFyZ2xpc3QpCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICxAZm9ybXMpKSkpKSkKCjs7IEludGVybmFsIGRhdGEgdXNlZCB0byBk
ZXRlY3QgZW5kbGVzcyByZWN1cnNpb24gaW4gJ2NsLXR5cGUtb2YnLgooZGVmdmFyIGNsLS10
eXBlLW9iamVjdCAobWFrZS1zeW1ib2wgInZvaWQiKSkKOzsgRW5zdXJlIGVhY2ggdHlwZSBz
YXRpc2ZpZXMgYGVxbCcuCihkZWZ2YXIgY2wtLXR5cGUtdW5pcXVlIChtYWtlLWhhc2gtdGFi
bGUgOnRlc3QgJ2VxdWFsKQogICJSZWNvcmQgYW4gdW5pcXVlIHZhbHVlIG9mIGVhY2ggdHlw
ZS4iKQoKOzsgRklYTUU6IGBjbC10eXBlcy1vZicgQ1BVIGNvc3QgaXMgcHJvcG9ydGlvbmFs
IHRvIHRoZSBudW1iZXIgb2YgdHlwZXMKOzsgZGVmaW5lZCB3aXRoIGBjbC1kZWZ0eXBlJywg
c28gdGhlIG1vcmUgcG9wdWxhciBpdCBnZXRzLCB0aGUgc2xvd2VyCjs7IGl0IGJlY29tZXMu
ICBBbmQgb2YgY291cnNlLCB0aGUgY29zdCBvZiBlYWNoIHR5cGUgY2hlY2sgaXMKOzsgdW5i
b3VuZGVkLCBzbyBhIHNpbmdsZSAiZXhwZW5zaXZlIiB0eXBlIGNhbiBzbG93IGV2ZXJ5dGhp
bmcgZG93bgo7OyBmdXJ0aGVyLgo7Owo7OyBUaGUgdXN1YWwgZGlzcGF0Y2ggaXMKOzsKOzsg
ICAobGFtYmRhIChhcmcgJnJlc3QgYXJncykKOzsgICAgIChsZXQgKChmIChnZXRoYXNoIChj
bC10eXBlb2YgYXJnKSBwcmVjb21wdXRlZC1tZXRob2RzLXRhYmxlKSkpCjs7ICAgICAgIChp
ZiBmCjs7ICAgICAgICAgICAoYXBwbHkgZiBhcmcgYXJncykKOzsgICAgICAgICA7OyBTbG93
IGNhc2Ugd2hlbiBlbmNvdW50ZXJpbmcgYSBuZXcgdHlwZQo7OyAgICAgICAgIC4uLikpKQo7
Owo7OyB3aGVyZSBvZnRlbiB0aGUgbW9zdCBleHBlbnNpdmUgcGFydCBpcyBgJnJlc3QnICh3
aGljaCBoYXMgdG8KOzsgYWxsb2NhdGUgYSBsaXN0IGZvciB0aG9zZSByZW1haW5pbmcgYXJn
dW1lbnRzKSwKOzsKOzsgU28gd2UncmUgdGFsa2luZyBhYm91dCByZXBsYWNpbmcKOzsKOzsg
ICAmcmVzdCArIGNsLXR5cGUtb2YgKyBnZXRoYXNoICsgaWYgKyBhcHBseQo7Owo7OyB3aXRo
IGEgZnVuY3Rpb24gdGhhdCBsb29wcyBvdmVyIE4gdHlwZXMsIGNhbGxpbmcgYGNsLXR5cGVw
JyBvbiBlYWNoCjs7IG9uZSBvZiB0aGVtIChgY2wtdHlwZXAnIGl0c2VsZiBiZWluZyBhIHJl
Y3Vyc2l2ZSBmdW5jdGlvbiB0aGF0Cjs7IGJhc2ljYWxseSBpbnRlcnByZXRzIHRoZSB0eXBl
IGxhbmd1YWdlKS4gIFRoaXMgaXMgZ29pbmcgdG8gc2xvdwo7OyBkb3duIGRpc3BhdGNoIHZl
cnkgc2lnbmlmaWNhbnRseSBmb3IgdGhvc2UgZ2VuZXJpYyBmdW5jdGlvbnMgdGhhdAo7OyBo
YXZlIGEgbWV0aG9kIHRoYXQgZGlzcGF0Y2hlcyBvbiBhIHVzZXIgZGVmaW5lZCB0eXBlLCBj
b21wYXJlZCB0bwo7OyB0aG9zZSB0aGF0IGRvbid0Lgo7Owo7OyBBIHBvc3NpYmxlIGZ1cnRo
ZXIgaW1wcm92ZW1lbnQ6Cjs7Cjs7IC0gYmFzZWQgb24gdGhlIFBBUkVOVFMgZGVjbGFyYXRp
b24sIGNyZWF0ZSBhIG1hcCBmcm9tIGJ1aWx0aW4tdHlwZQo7OyAgIHRvIHRoZSBzZXQgb2Yg
Y2wtdHlwZXMgdGhhdCBoYXZlIHRoYXQgYnVpbHRpbi10eXBlIGFtb25nIHRoZWlyCjs7ICAg
cGFyZW50cy4gIFRoYXQgcHJlc3VtZXMgc29tZSBQQVJFTlRTIGluY2x1ZGUgc29tZSBidWls
dGluLXR5cGVzLAo7OyAgIG9idmlvdXNseSBvdGhlcndpc2UgdGhlIG1hcCB3aWxsIGJlIHRy
aXZpYWwgd2l0aCBhbGwgY2wtdHlwZXMKOzsgICBhc3NvY2lhdGVkIHdpdGggdGhlIGB0JyAi
ZHVtbXkgcGFyZW50Ii4gIFsgV2UgY291bGQgZXZlbiBnbyBjcmF6eQo7OyAgIGFuZCB0cnkg
YW5kIGd1ZXNzIFBBUkVOVFMgd2hlbiBub3QgcHJvdmlkZWQsIGJ5IGFuYWx5emluZyB0aGUK
OzsgICB0eXBlJ3MgZGVmaW5pdGlvbi4gXQo7Owo7OyAtIGluIGBjbC10eXBlcy1vZicgc3Rh
cnQgYnkgY2FsbGluZyBgY2wtdHlwZS1vZicsIHRoZW4gdXNlIHRoZSBtYXAKOzsgICB0byBm
aW5kIHdoaWNoIGNsLXR5cGVzIG1heSBuZWVkIHRvIGJlIGNoZWNrZWQuCjs7CihkZWZ1biBj
bC10eXBlcy1vZiAob2JqZWN0KQogICJSZXR1cm4gdGhlIHR5cGVzIE9CSkVDVCBiZWxvbmdz
IHRvLgpSZXR1cm4gYW4gdW5pcXVlIGxpc3Qgb2YgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8s
IG9yZGVyZWQgZnJvbSB0aGUKbW9zdCBzcGVjaWZpYyB0eXBlIHRvIHRoZSBtb3N0IGdlbmVy
YWwuIgogIDs7IElnbm9yZSByZWN1cnNpdmUgY2FsbCBvbiB0aGUgc2FtZSBPQkpFQ1QsIHdo
aWNoIGNhbiBsZWdpdGltYXRlbHkKICA7OyBvY2N1ciB3aGVuIGEgcGFyZW50IHR5cGUgaXMg
Y2hlY2tpbmcgd2hldGhlciBhbiBvYmplY3QncyB0eXBlIGlzCiAgOzsgdGhhdCBvZiBvbmUg
b2YgaXRzIGNoaWxkcmVuLgogICh1bmxlc3MgKGVxIG9iamVjdCBjbC0tdHlwZS1vYmplY3Qp
CiAgICAobGV0ICgoY2wtLXR5cGUtb2JqZWN0IG9iamVjdCkKICAgICAgICAgIChmb3VuZCAo
bGlzdCAoY2wtLXR5cGUtcGFyZW50cyAoY2wtdHlwZS1vZiBvYmplY3QpKSkpKQogICAgICA7
OyBCdWlsZCBhIERBRyBvZiBhbGwgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8uCiAgICAgIChk
b2xpc3QgKHR5cGUgY2wtLXR5cGUtbGlzdCkKICAgICAgICAoYW5kCgkgOzsgSWYgQkFSIGlz
IGRlY2xhcmVkIGFzIGEgcGFyZW50IG9mIEZPTyBhbmQgYGNsLXR5cGVzLW9mJwoJIDs7IGhh
cyBhbHJlYWR5IGRlY2lkZWQgdGhhdCB0aGUgdmFsdWUgaXMgb2YgdHlwZSBGT08sIHRoZW4g
d2UKCSA7OyBhbHJlYWR5IGtub3cgQkFSIHdpbGwgYmUgaW4gdGhlIG91dHB1dCBhbnl3YXkg
YW5kIHRoZXJlJ3MKCSA7OyBubyBwb2ludCB0ZXN0aW5nIEJBUi4gIFNvLCBza2lwIHR5cGUg
YWxyZWFkeSBzZWxlY3RlZCBhcwoJIDs7IHBhcmVudCBvZiBhbm90aGVyIHR5cGUsIGFzc3Vt
aW5nIHRoYXQsIG1vc3Qgb2YgdGhlIHRpbWUsCgkgOzsgYGFzc3EnIHdpbGwgYmUgZmFzdGVy
IHRoYW4gYGNsLXR5cGVwJy4KICAgICAgICAgKG51bGwgKGFzc3EgdHlwZSBmb3VuZCkpCiAg
ICAgICAgIDs7IFNraXAgdHlwZSBub3QgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScuCiAgICAg
ICAgIChjbC10eXBlcCAoY2wtLWZpbmQtY2xhc3MgdHlwZSkgJ2NsLXR5cGUtY2xhc3MpCiAg
ICAgICAgIDs7IElmIE9CSkVDVCBpcyBvZiB0eXBlLCBhZGQgdHlwZSBhbmQgcGFyZW50cyB0
byB0aGUgREFHLgogICAgICAgICAoY2wtdHlwZXAgb2JqZWN0IHR5cGUpCgkgOzsgKGRvbGlz
dCAocCAoY2wtLXR5cGUtcGFyZW50cyB0eXBlKSkKCSA7OyAgIChwdXNoIChjbC0tdHlwZS1w
YXJlbnRzIHApIGZvdW5kKSkKCSA7OyBFcXVpdmFsZW50IHRvIHRoZSBgZG9saXN0JyBhYm92
ZSwgYnV0IGZhc3RlcjogYXZvaWQgdG8KCSA7OyByZWNvbXB1dGUgc2V2ZXJhbCBsaXN0cyBv
ZiBwYXJlbnRzIHdlIGFscmVhZHkga25vdy4KCSAobGV0ICgocGwgKGNsLS10eXBlLXBhcmVu
dHMgdHlwZSkpKQoJICAgKHdoaWxlIHBsCgkgICAgIChwdXNoIHBsIGZvdW5kKQoJICAgICAo
c2V0cSBwbCAoY2RyIHBsKSkpKQoJICkpCiAgICAgIDs7IENvbXB1dGUgYW4gb3JkZXJlZCBs
aXN0IG9mIHR5cGVzIGZyb20gdGhlIGNvbGxlY3RlZCBEQUcuCiAgICAgIChzZXRxIGZvdW5k
IChtZXJnZS1vcmRlcmVkLWxpc3RzIGZvdW5kKSkKICAgICAgOzsgUmV0dXJuIGFuIHVuaXF1
ZSB2YWx1ZSBvZiB0aGlzIGxpc3Qgb2YgdHlwZXMsIHdoaWNoIGlzIGFsc28KICAgICAgOzsg
dGhlIGxpc3Qgb2Ygc3BlY2lmaWVycyBmb3IgdGhpcyB0eXBlLgogICAgICAod2l0aC1tZW1v
aXphdGlvbiAoZ2V0aGFzaCBmb3VuZCBjbC0tdHlwZS11bmlxdWUpCiAgICAgICAgZm91bmQp
KSkpCgo7OzsgTWV0aG9kIGRpc3BhdGNoaW5nCjs7CihjbC1nZW5lcmljLWRlZmluZS1nZW5l
cmFsaXplciBjbC0tdHlwZS1nZW5lcmFsaXplcgogIDIwIDs7ICJ0eXBlb2YiIDwgImNsLXR5
cGVzLW9mIiA8ICJoZWFkIiBwcmlvcml0eQogIChsYW1iZGEgKG9iaiAmcmVzdCBfKSBgKGNs
LXR5cGVzLW9mICxvYmopKQogIChsYW1iZGEgKHRhZyAmcmVzdCBfKSAoaWYgKGNvbnNwIHRh
ZykgdGFnKSkpCgooY2wtZGVmbWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6ZXJzIDpleHRy
YSAiY2wtdHlwZXMtb2YiICh0eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBvbiB0eXBl
cy4iCiAgKGlmIChjbC0tdHlwZS1wIHR5cGUpCiAgICAgIChsaXN0IGNsLS10eXBlLWdlbmVy
YWxpemVyKQogICAgKGNsLWNhbGwtbmV4dC1tZXRob2QpKSkKCihwcm92aWRlICdjbC10eXBl
cykKCjs7OyBjbC10eXBlcy5lbCBlbmRzIGhlcmUK
--------------oQNclki4E7GToXoSUh4I3NAy--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Apr 2025 10:12:01 +0000
Resent-Message-ID: <handler.77725.B77725.1745057498952 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.1745057498952
(code B ref 77725); Sat, 19 Apr 2025 10:12:01 +0000
Received: (at 77725) by debbugs.gnu.org; 19 Apr 2025 10:11:38 +0000
Received: from localhost ([127.0.0.1]:58416 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u65Ae-0000FD-UH
for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 06:11:37 -0400
Received: from smtp-22.smtpout.orange.fr ([80.12.242.22]:34475
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u65Ab-0000En-FY
for 77725 <at> debbugs.gnu.org; Sat, 19 Apr 2025 06:11:35 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 65ATujIsUaoZo65AWuqEVN; Sat, 19 Apr 2025 12:11:31 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745057491;
bh=2S4fkNLAmSMCeC1rkn6KT+r+DwuAUFveY3hGWDbV/gA=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=YJQ+4z/LSMJrT8QtbCY66mTK26yERR2q6q+g6qZhzF0G/BLqefI4zA0TZ+AEmejuG
zzXtMY/zFwjV223DHcVIejqvpeA4JkjB5I0s4MTeMZXDCrZ2wBaKeq2Xp/B/vgZcRw
q5v3K+O18i9ZL7PQ/ULn9KAfH441FFnKHf6eEgLAaVO+Eh4AHHtIcVVFi26uACkHY7
vrBTkL4D4W08xOiWFf/aElAjz7znkhW/QE+b4RBcLuB5FOxxU3dPocbU6Zgp04FOBy
BLbMMliHth/8G/dH/m86rwo0ktiYNGnnOaGfozIGqgmKgtCUhcThVDA2Poq4rpOM2r
e7RxZ9W/EgV/g==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sat, 19 Apr 2025 12:11:31 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------4ow9Gxj9UDAJ0uo5JML1T0bX"
Message-ID: <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
Date: Sat, 19 Apr 2025 12:11:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: David Ponce <da_vid@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------4ow9Gxj9UDAJ0uo5JML1T0bX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
> Regarding a possible merge in cl-lib, should cl-types.el be copied at
> the end of cl-lib, after cl-macs is loaded? If I correctly understand
> the logic of loading these libs ;-)
I looked into this a bit more, and it turns out that cl-generic
depends on cl-lib, so the code in cl-types.el that depends on
cl-generic can't go in cl-lib. This concern the two definitions
at the end of cl-types.el:
(cl-generic-define-generalizer cl--type-generalizer
...
)
(cl-defmethod cl-generic-generalizers :extra "cl-types-of" (type)
...
)
which could logically go in cl-generic?
I attached a slightly updated version of cl-types.el, mainly to check
first if a type is of class `cl-type-class' in `cl-types-of', and to
use the predicate `cl-type-class-p' simpler than `cl-typep'.
Happy Easter weekend :-)
--------------4ow9Gxj9UDAJ0uo5JML1T0bX
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl
biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCihldmFsLXdoZW4tY29t
cGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5kLWNsYXNzLgoKOzsgRXh0
ZW5kIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgZGF0YSB0eXBlcyB3aGljaCBhcmUgYWxzbyB2
YWxpZAo7OyBhcmd1bWVudCB0eXBlcyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlv
biBtZXRob2RzIChzZWUgYWxzbwo7OyA8aHR0cHM6Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1
Z3JlcG9ydC5jZ2k/YnVnPTc3NzI1PikuCjs7Cjs7IFRoZSBtYWluIGVudHJ5IHBvaW50cyBh
cmU6Cjs7Cjs7IC0gYGNsLWRlZnR5cGUnLCB0aGF0IGRlZmluZXMgbmV3IGRhdGEgdHlwZXMu
Cjs7Cjs7IC0gYGNsLXR5cGVzLW9mJywgdGhhdCByZXR1cm5zIHRoZSB0eXBlcyBhbiBvYmpl
Y3QgYmVsb25ncyB0by4KCihkZWZ2YXIgY2wtLXR5cGUtbGlzdCBuaWwKICAiTGlzdCBvZiBk
ZWZpbmVkIHR5cGVzIHRvIGxvb2t1cCBmb3IgbWV0aG9kIGRpc3BhdGNoaW5nLiIpCgo7OyBG
SVhNRTogVGhlIGBjbC1kZWZ0eXBlLWhhbmRsZXInIHByb3BlcnR5IHNob3VsZCBhcmd1YWJs
eSBiZSB0dXJuZWQKOzsgaW50byBhIGZpZWxkIG9mIHRoaXMgc3RydWN0IChidXQgaXQgaGFz
IHBlcmZvcm1hbmNlIGFuZAo7OyBjb21wYXRpYmlsaXR5IGltcGxpY2F0aW9ucywgc28gbGV0
J3Mgbm90IG1ha2UgdGhhdCBjaGFuZ2UgZm9yIG5vdykuCihjbC1kZWZzdHJ1Y3QKICAgIChj
bC10eXBlLWNsYXNzCiAgICAgKDppbmNsdWRlIGNsLS1jbGFzcykKICAgICAoOm5vaW5saW5l
IHQpCiAgICAgKDpjb25zdHJ1Y3RvciBuaWwpCiAgICAgKDpjb25zdHJ1Y3RvciBjbC0tdHlw
ZS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAgICAobmFtZQogICAgICAgICAgICAgICAg
ICAgIGRvY3N0cmluZwogICAgICAgICAgICAgICAgICAgIHBhcmVudC10eXBlcwogICAgICAg
ICAgICAgICAgICAgICZhdXggKHBhcmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAo
bWFwY2FyCiAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKHR5cGUpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKG9yIChjbC0tZmluZC1jbGFzcyB0eXBlKQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIlVua25vd24gdHlwZTogJVMi
IHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5cGVzKSkpKQog
ICAgICg6Y29waWVyIG5pbCkpCiAgIlR5cGUgZGVzY3JpcHRvcnMgZm9yIHR5cGVzIGRlZmlu
ZWQgYnkgYGNsLWRlZnR5cGUnLiIpCgooZGVmdW4gY2wtLXR5cGUtcCAob2JqZWN0KQogICJS
ZXR1cm4gbm9uLW5pbCBpZiBPQkpFQ1QgaXMgYSB1c2VkIGRlZmluZWQgdHlwZS4KVGhhdCBp
cywgYSB0eXBlIG9mIGNsYXNzIGBjbC10eXBlLWNsYXNzJy4iCiAgKGFuZCAoc3ltYm9scCBv
YmplY3QpIChjbC10eXBlLWNsYXNzLXAgKGNsLS1maW5kLWNsYXNzIG9iamVjdCkpKSkKCihk
ZWZtYWNybyBjbC0tdHlwZS1wYXJlbnRzIChuYW1lKQogICJHZXQgcGFyZW50cyBvZiB0eXBl
IHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCByZXByZXNlbnRpbmcgYSB0eXBlLiIKICBg
KGNsLS1jbGFzcy1hbGxwYXJlbnRzIChjbC0tZmluZC1jbGFzcyAsbmFtZSkpKQoKKGRlZnVu
IGNsLS10eXBlLWNoaWxkcmVuIChuYW1lKQogICJHZXQgY2hpbGRyZW4gb2YgdGhlIHR5cGUg
d2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClJldHVy
biBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgogIChjbC1jaGVjay10eXBlIG5h
bWUgKHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAobGV0IChjaGlsZHJlbikKICAgIChkb2xp
c3QgKGVsdCBjbC0tdHlwZS1saXN0KQogICAgICAob3IgKGVxIG5hbWUgZWx0KQogICAgICAg
ICAgKGlmIChtZW1xIG5hbWUgKGNsLS10eXBlLXBhcmVudHMgZWx0KSkKICAgICAgICAgICAg
ICAocHVzaCBlbHQgY2hpbGRyZW4pKSkpCiAgICBjaGlsZHJlbikpCgooZGVmdW4gY2wtLXR5
cGUtZGFnICgpCiAgIlJldHVybiBhIERBRyBmcm9tIHRoZSBsaXN0IG9mIGRlZmluZWQgdHlw
ZXMuIgogIChtYXBjYXIgKGxhbWJkYSAodHlwZSkgKGNsLS1jbGFzcy1hbGxwYXJlbnRzIChj
bC0tZmluZC1jbGFzcyB0eXBlKSkpCiAgICAgICAgICBjbC0tdHlwZS1saXN0KSkKCjs7IEtl
ZXAgaXQgZm9yIG5vdywgZm9yIHRlc3RpbmcuCihkZWZ1biBjbC0tdHlwZS11bmRlZmluZSAo
bmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0aW9ucyBvZiB0eXBlIHdpdGggTkFNRS4KTkFN
RSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlwZS4KU2lnbmFsIGFu
IGVycm9yIGlmIG90aGVyIHR5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICAoZGVjbGFyZS1m
dW5jdGlvbiBjbC1yZW1wcm9wICJjbC1leHRyYSIgKHN5bWJvbCBwcm9wbmFtZSkpCiAgKGNs
LWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogICh3aGVuLWxldCog
KChjaGlsZHJlbiAoYW5kIChjbC0tdHlwZS1wIG5hbWUpCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKGNsLS10eXBlLWNoaWxkcmVuIG5hbWUpKSkpCiAgICAoZXJyb3IgIlR5cGUg
aGFzIGNoaWxkcmVuOiAlUyIgY2hpbGRyZW4pKQogIChjbC1yZW1wcm9wIG5hbWUgJ2NsLS1j
bGFzcykKICAoY2wtcmVtcHJvcCBuYW1lICdjbC1kZWZ0eXBlLWhhbmRsZXIpCiAgKHNldHEg
Y2wtLXR5cGUtbGlzdCAoZGVscSBuYW1lIGNsLS10eXBlLWxpc3QpKSkKCihkZWZ1biBjbC0t
dHlwZS1nZW5lcmFsaXplIChuYW1lIHBhcmVudHMgJm9wdGlvbmFsIGRvY3N0cmluZykKICAi
R2VuZXJhbGl6ZSB0eXBlIHdpdGggTkFNRSBmb3IgbWV0aG9kIGRpc3BhdGNoaW5nLgpQQVJF
TlRTIGlzIGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZiwgb3IgbmlsLgpE
T0NTVFJJTkcgaXMgYW4gb3B0aW9uYWwgZG9jdW1lbnRhdGlvbiBzdHJpbmcuIgogIChsZXQg
KChvbGR0bGlzdCAoY29weS1zZXF1ZW5jZSBjbC0tdHlwZS1saXN0KSkKICAgICAgICAob2xk
cGxpc3QgKGNvcHktc2VxdWVuY2UgKHN5bWJvbC1wbGlzdCBuYW1lKSkpKQogICAgKGNvbmRp
dGlvbi1jYXNlIGVycgogICAgICAgIChsZXQqICgoY2xhc3MgKGNsLS1maW5kLWNsYXNzIG5h
bWUpKQogICAgICAgICAgICAgICAocmVjb3JkZWQgKG1lbXEgbmFtZSBjbC0tdHlwZS1saXN0
KSkpCiAgICAgICAgICAoaWYgKG51bGwgY2xhc3MpCiAgICAgICAgICAgICAgKG9yIChudWxs
IHJlY29yZGVkKQogICAgICAgICAgICAgICAgICAoZXJyb3IgIlR5cGUgZ2VuZXJhbGl6ZWQs
IGJ1dCBkb2Vzbid0IGV4aXN0IikpCiAgICAgICAgICAgIChvciByZWNvcmRlZCAoZXJyb3Ig
IlR5cGUgZXhpc3RzLCBidXQgbm90IGdlbmVyYWxpemVkIikpCiAgICAgICAgICAgIChvciAo
Y2wtdHlwZS1jbGFzcy1wIGNsYXNzKQogICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGlu
IGFub3RoZXIgY2xhc3M6ICVTIiAodHlwZS1vZiBjbGFzcykpKSkKICAgICAgICAgIChpZiAo
bWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGluIHBhcmVu
dHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9y
IGZvciBOQU1FLgogICAgICAgICAgKHNldGYgKGNsLS1maW5kLWNsYXNzIG5hbWUpCiAgICAg
ICAgICAgICAgICAoY2wtLXR5cGUtY2xhc3MtbWFrZSBuYW1lIGRvY3N0cmluZyBwYXJlbnRz
KSkKICAgICAgICAgIDs7IFJlY29yZCBuZXcgdHlwZSBub3cgdG8gaW5jbHVkZSBpdHMgZGVw
ZW5kZW5jeSBpbiB0aGUgREFHLgogICAgICAgICAgKG9yIHJlY29yZGVkIChwdXNoIG5hbWUg
Y2wtLXR5cGUtbGlzdCkpCiAgICAgICAgICA7OyBgY2wtdHlwZXMtb2YnIGl0ZXJhdGVzIHRo
cm91Z2ggYWxsIGtub3duIHR5cGVzIHRvIGNvbGxlY3QKICAgICAgICAgIDs7IGFsbCB0aG9z
ZSBhbiBvYmplY3QgYmVsb25ncyB0bywgc29ydGVkIGZyb20gdGhlIG1vc3QKICAgICAgICAg
IDs7IHNwZWNpZmljIHR5cGUgdG8gdGhlIG1vcmUgZ2VuZXJhbCB0eXBlLiAgU28sIGtlZXAg
dGhlCiAgICAgICAgICA7OyBnbG9iYWwgbGlzdCBpbiB0aGlzIG9yZGVyLgogICAgICAgICAg
KHNldHEgY2wtLXR5cGUtbGlzdAogICAgICAgICAgICAgICAgKG1lcmdlLW9yZGVyZWQtbGlz
dHMKICAgICAgICAgICAgICAgICAoY2wtLXR5cGUtZGFnKQogICAgICAgICAgICAgICAgIChs
YW1iZGEgKF8pIChlcnJvciAiSW52YWxpZCBkZXBlbmRlbmN5IGdyYXBoIikpKSkpCiAgICAg
IChlcnJvcgogICAgICAgOzsgT24gZXJyb3IgcmVzdG9yZSBwcmV2aW91cyBkYXRhLgogICAg
ICAgKHNldHEgY2wtLXR5cGUtbGlzdCBvbGR0bGlzdCkKICAgICAgIChzZXRmIChzeW1ib2wt
cGxpc3QgbmFtZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAiRGVmaW5lICVT
IGZhaWxlZDogJXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJvci1tZXNzYWdl
LXN0cmluZyBlcnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gY2wtZGVmdHlw
ZTIgKG5hbWUgYXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBhcyBhIG5ldyBk
YXRhIHR5cGUuClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBgY2wtdHlwZWNh
c2UnLCBgY2wtY2hlY2stdHlwZScsIGV0YywKYW5kIGFzIGFyZ3VtZW50IHR5cGUgZm9yIGRp
c3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KCkFSR0xJU1QgaXMgYSBDb21t
b24gTGlzcCBhcmd1bWVudCBsaXN0IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5CmBjbC1kZWZt
YWNybycuICBCT0RZIGZvcm1zIGFyZSBldmFsdWF0ZWQgYW5kIHNob3VsZCByZXR1cm4gYSB0
eXBlCnNwZWNpZmllciB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUgKHNlZSB0aGUg
SW5mbyBub2RlIGAoY2wpIFR5cGUKUHJlZGljYXRlcycgaW4gdGhlIEdOVSBFbWFjcyBDb21t
b24gTGlzcCBFbXVsYXRpb24gbWFudWFsKS4KCklmIHRoZXJlIGlzIGEgYGRlY2xhcmUnIGZv
cm0gaW4gQk9EWSwgdGhlIHNwZWMgKHBhcmVudHMgUEFSRU5UUykgaXMKcmVjb2duaXplZCB0
byBzcGVjaWZ5IGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZi4gIEZvcgpp
bnN0YW5jZToKCiAgKGNsLWRlZnR5cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25hbCBiaXRz
KQogICAgXCJVbnNpZ25lZCBpbnRlZ2VyLlwiCiAgICAobGlzdCBcXD0naW50ZWdlciAwIChp
ZiAoZXEgYml0cyBcXD0nKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAoY2wtZGVm
dHlwZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgIFwiVW5zaWduZWQgOC1iaXRzIGludGVnZXIu
XCIKICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNp
Z25lZC1ieXRlIDgpKQoKVGhlIGxpc3Qgb2YgUEFSRU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRo
ZSBvcmRlciBvZiBtZXRob2RzIGludm9jYXRpb24sCmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5
IGNhdXNlIGluY29ycmVjdCBvcmRlcmluZyBvZiBtZXRob2RzLCB3aGlsZQpleHRyYW5lb3Vz
IFBBUkVOVFMgbWF5IGNhdXNlIHVzZSBvZiBleHRyYW5lb3VzIG1ldGhvZHMuIgogIChkZWNs
YXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1zdHJpbmcgMykgKGluZGVudCAyKSkKICAo
cGNhc2UtbGV0KgogICAgICAoKGAoLGRlY2xzIC4gLGZvcm1zKSAobWFjcm9leHAtcGFyc2Ut
Ym9keSBib2R5KSkKICAgICAgIChkb2NzdHJpbmcgKGlmIChzdHJpbmdwIChjYXIgZGVjbHMp
KQogICAgICAgICAgICAgICAgICAgICAgKGNhciBkZWNscykKICAgICAgICAgICAgICAgICAg
ICAoY2FkciAoYXNzcSA6ZG9jdW1lbnRhdGlvbiBkZWNscykpKSkKICAgICAgIChwYXJlbnRz
IChjZHIgKGFzc3EgJ3BhcmVudHMgKGNkciAoYXNzcSAnZGVjbGFyZSBkZWNscykpKSkpKQog
ICAgKGFuZCBwYXJlbnRzIGFyZ2xpc3QKICAgICAgICAgKGVycm9yICJQYXJlbnRzIHNwZWNp
ZmllZCwgYnV0IGFyZ2xpc3Qgbm90IGVtcHR5IikpCiAgICAoaWYgZG9jc3RyaW5nIChzZXRx
IGZvcm1zIChjb25zIGRvY3N0cmluZyBmb3JtcykpKQogICAgYChjbC1ldmFsLXdoZW4gKGNv
bXBpbGUgbG9hZCBldmFsKQogICAgICAgKGNsLS10eXBlLWdlbmVyYWxpemUgJyxuYW1lICcs
cGFyZW50cyAsZG9jc3RyaW5nKQogICAgICAgKGRlZmluZS1zeW1ib2wtcHJvcCAnLG5hbWUg
J2NsLWRlZnR5cGUtaGFuZGxlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAoY2wtZnVu
Y3Rpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKCZjbC1kZWZzICgn
KikgLEBhcmdsaXN0KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAsQGZvcm1zKSkp
KSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3MgcmVjdXJzaW9u
IGluICdjbC10eXBlLW9mJy4KKGRlZnZhciBjbC0tdHlwZS1vYmplY3QgKG1ha2Utc3ltYm9s
ICJ2b2lkIikpCjs7IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwnLgooZGVmdmFy
IGNsLS10eXBlLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkKICAiUmVj
b3JkIGFuIHVuaXF1ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCjs7IEZJWE1FOiBgY2wtdHlw
ZXMtb2YnIENQVSBjb3N0IGlzIHByb3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9mIHR5cGVz
Cjs7IGRlZmluZWQgd2l0aCBgY2wtZGVmdHlwZScsIHNvIHRoZSBtb3JlIHBvcHVsYXIgaXQg
Z2V0cywgdGhlIHNsb3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5kIG9mIGNvdXJzZSwgdGhlIGNv
c3Qgb2YgZWFjaCB0eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRlZCwgc28gYSBzaW5nbGUgImV4
cGVuc2l2ZSIgdHlwZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRvd24KOzsgZnVydGhlci4KOzsK
OzsgVGhlIHVzdWFsIGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxhbWJkYSAoYXJnICZyZXN0IGFy
Z3MpCjs7ICAgICAobGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlwZW9mIGFyZykgcHJlY29tcHV0
ZWQtbWV0aG9kcy10YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7OyAgICAgICAgICAgKGFwcGx5
IGYgYXJnIGFyZ3MpCjs7ICAgICAgICAgOzsgU2xvdyBjYXNlIHdoZW4gZW5jb3VudGVyaW5n
IGEgbmV3IHR5cGUKOzsgICAgICAgICAuLi4pKSkKOzsKOzsgd2hlcmUgb2Z0ZW4gdGhlIG1v
c3QgZXhwZW5zaXZlIHBhcnQgaXMgYCZyZXN0JyAod2hpY2ggaGFzIHRvCjs7IGFsbG9jYXRl
IGEgbGlzdCBmb3IgdGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50cyksCjs7Cjs7IFNvIHdlJ3Jl
IHRhbGtpbmcgYWJvdXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJlc3QgKyBjbC10eXBlLW9mICsg
Z2V0aGFzaCArIGlmICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1bmN0aW9uIHRoYXQgbG9vcHMg
b3ZlciBOIHR5cGVzLCBjYWxsaW5nIGBjbC10eXBlcCcgb24gZWFjaAo7OyBvbmUgb2YgdGhl
bSAoYGNsLXR5cGVwJyBpdHNlbGYgYmVpbmcgYSByZWN1cnNpdmUgZnVuY3Rpb24gdGhhdAo7
OyBiYXNpY2FsbHkgaW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5ndWFnZSkuICBUaGlzIGlzIGdv
aW5nIHRvIHNsb3cKOzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNpZ25pZmljYW50bHkgZm9yIHRo
b3NlIGdlbmVyaWMgZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBhIG1ldGhvZCB0aGF0IGRpc3Bh
dGNoZXMgb24gYSB1c2VyIGRlZmluZWQgdHlwZSwgY29tcGFyZWQgdG8KOzsgdGhvc2UgdGhh
dCBkb24ndC4KOzsKOzsgQSBwb3NzaWJsZSBmdXJ0aGVyIGltcHJvdmVtZW50Ogo7Owo7OyAt
IGJhc2VkIG9uIHRoZSBQQVJFTlRTIGRlY2xhcmF0aW9uLCBjcmVhdGUgYSBtYXAgZnJvbSBi
dWlsdGluLXR5cGUKOzsgICB0byB0aGUgc2V0IG9mIGNsLXR5cGVzIHRoYXQgaGF2ZSB0aGF0
IGJ1aWx0aW4tdHlwZSBhbW9uZyB0aGVpcgo7OyAgIHBhcmVudHMuICBUaGF0IHByZXN1bWVz
IHNvbWUgUEFSRU5UUyBpbmNsdWRlIHNvbWUgYnVpbHRpbi10eXBlcywKOzsgICBvYnZpb3Vz
bHkgb3RoZXJ3aXNlIHRoZSBtYXAgd2lsbCBiZSB0cml2aWFsIHdpdGggYWxsIGNsLXR5cGVz
Cjs7ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBgdCcgImR1bW15IHBhcmVudCIuICBbIFdlIGNv
dWxkIGV2ZW4gZ28gY3JhenkKOzsgICBhbmQgdHJ5IGFuZCBndWVzcyBQQVJFTlRTIHdoZW4g
bm90IHByb3ZpZGVkLCBieSBhbmFseXppbmcgdGhlCjs7ICAgdHlwZSdzIGRlZmluaXRpb24u
IF0KOzsKOzsgLSBpbiBgY2wtdHlwZXMtb2YnIHN0YXJ0IGJ5IGNhbGxpbmcgYGNsLXR5cGUt
b2YnLCB0aGVuIHVzZSB0aGUgbWFwCjs7ICAgdG8gZmluZCB3aGljaCBjbC10eXBlcyBtYXkg
bmVlZCB0byBiZSBjaGVja2VkLgo7OwooZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKICAi
UmV0dXJuIHRoZSB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBs
aXN0IG9mIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qg
c3BlY2lmaWMgdHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJz
aXZlIGNhbGwgb24gdGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAg
Ozsgb2NjdXIgd2hlbiBhIHBhcmVudCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIgYW4gb2Jq
ZWN0J3MgdHlwZSBpcwogIDs7IHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJlbi4KICAodW5s
ZXNzIChlcSBvYmplY3QgY2wtLXR5cGUtb2JqZWN0KQogICAgKGxldCAoKGNsLS10eXBlLW9i
amVjdCBvYmplY3QpCiAgICAgICAgICAoZm91bmQgKGxpc3QgKGNsLS10eXBlLXBhcmVudHMg
KGNsLXR5cGUtb2Ygb2JqZWN0KSkpKSkKICAgICAgOzsgQnVpbGQgYSBEQUcgb2YgYWxsIHR5
cGVzIE9CSkVDVCBiZWxvbmdzIHRvLgogICAgICAoZG9saXN0ICh0eXBlIGNsLS10eXBlLWxp
c3QpCiAgICAgICAgKGFuZAogICAgICAgICA7OyBTa2lwIHR5cGUgbm90IGRlZmluZWQgYnkg
YGNsLWRlZnR5cGUnLgogICAgICAgICAoY2wtdHlwZS1jbGFzcy1wIChjbC0tZmluZC1jbGFz
cyB0eXBlKSkKICAgICAgICAgOzsgSWYgQkFSIGlzIGRlY2xhcmVkIGFzIGEgcGFyZW50IG9m
IEZPTyBhbmQgYGNsLXR5cGVzLW9mJwogICAgICAgICA7OyBoYXMgYWxyZWFkeSBkZWNpZGVk
IHRoYXQgdGhlIHZhbHVlIGlzIG9mIHR5cGUgRk9PLCB0aGVuIHdlCiAgICAgICAgIDs7IGFs
cmVhZHkga25vdyBCQVIgd2lsbCBiZSBpbiB0aGUgb3V0cHV0IGFueXdheSBhbmQgdGhlcmUn
cwogICAgICAgICA7OyBubyBwb2ludCB0ZXN0aW5nIEJBUi4gIFNvLCBza2lwIHR5cGUgYWxy
ZWFkeSBzZWxlY3RlZCBhcwogICAgICAgICA7OyBwYXJlbnQgb2YgYW5vdGhlciB0eXBlLCBh
c3N1bWluZyB0aGF0LCBtb3N0IG9mIHRoZSB0aW1lLAogICAgICAgICA7OyBgYXNzcScgd2ls
bCBiZSBmYXN0ZXIgdGhhbiBgY2wtdHlwZXAnLgogICAgICAgICAobnVsbCAoYXNzcSB0eXBl
IGZvdW5kKSkKICAgICAgICAgOzsgSWYgT0JKRUNUIGlzIG9mIHR5cGUsIGFkZCB0eXBlIGFu
ZCBwYXJlbnRzIHRvIHRoZSBEQUcuCiAgICAgICAgIChjbC10eXBlcCBvYmplY3QgdHlwZSkK
ICAgICAgICAgOzsgKGRvbGlzdCAocCAoY2wtLXR5cGUtcGFyZW50cyB0eXBlKSkKICAgICAg
ICAgOzsgICAocHVzaCAoY2wtLXR5cGUtcGFyZW50cyBwKSBmb3VuZCkpCiAgICAgICAgIDs7
IEVxdWl2YWxlbnQgdG8gdGhlIGBkb2xpc3QnIGFib3ZlLCBidXQgZmFzdGVyOiBhdm9pZCB0
bwogICAgICAgICA7OyByZWNvbXB1dGUgc2V2ZXJhbCBsaXN0cyBvZiBwYXJlbnRzIHdlIGFs
cmVhZHkga25vdy4KICAgICAgICAgKGxldCAoKHBsIChjbC0tdHlwZS1wYXJlbnRzIHR5cGUp
KSkKICAgICAgICAgICAod2hpbGUgcGwKICAgICAgICAgICAgIChwdXNoIHBsIGZvdW5kKQog
ICAgICAgICAgICAgKHNldHEgcGwgKGNkciBwbCkpKSkKICAgICAgICAgKSkKICAgICAgOzsg
Q29tcHV0ZSBhbiBvcmRlcmVkIGxpc3Qgb2YgdHlwZXMgZnJvbSB0aGUgY29sbGVjdGVkIERB
Ry4KICAgICAgKHNldHEgZm91bmQgKG1lcmdlLW9yZGVyZWQtbGlzdHMgZm91bmQpKQogICAg
ICA7OyBSZXR1cm4gYW4gdW5pcXVlIHZhbHVlIG9mIHRoaXMgbGlzdCBvZiB0eXBlcywgd2hp
Y2ggaXMgYWxzbwogICAgICA7OyB0aGUgbGlzdCBvZiBzcGVjaWZpZXJzIGZvciB0aGlzIHR5
cGUuCiAgICAgICh3aXRoLW1lbW9pemF0aW9uIChnZXRoYXNoIGZvdW5kIGNsLS10eXBlLXVu
aXF1ZSkKICAgICAgICBmb3VuZCkpKSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGNs
LWdlbmVyaWMtZGVmaW5lLWdlbmVyYWxpemVyIGNsLS10eXBlLWdlbmVyYWxpemVyCiAgMjAg
OzsgInR5cGVvZiIgPCAiY2wtdHlwZXMtb2YiIDwgImhlYWQiIHByaW9yaXR5CiAgKGxhbWJk
YSAob2JqICZyZXN0IF8pIGAoY2wtdHlwZXMtb2YgLG9iaikpCiAgKGxhbWJkYSAodGFnICZy
ZXN0IF8pIChpZiAoY29uc3AgdGFnKSB0YWcpKSkKCihjbC1kZWZtZXRob2QgY2wtZ2VuZXJp
Yy1nZW5lcmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1vZiIgKHR5cGUpCiAgIlN1cHBvcnQg
Zm9yIGRpc3BhdGNoIG9uIHR5cGVzLiIKICAoaWYgKGNsLS10eXBlLXAgdHlwZSkKICAgICAg
KGxpc3QgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkp
KQoKKHByb3ZpZGUgJ2NsLXR5cGVzKQoKOzs7IGNsLXR5cGVzLmVsIGVuZHMgaGVyZQo=
--------------4ow9Gxj9UDAJ0uo5JML1T0bX--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Apr 2025 14:21:02 +0000
Resent-Message-ID: <handler.77725.B77725.1745072411772 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.1745072411772
(code B ref 77725); Sat, 19 Apr 2025 14:21:02 +0000
Received: (at 77725) by debbugs.gnu.org; 19 Apr 2025 14:20:11 +0000
Received: from localhost ([127.0.0.1]:34981 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u693D-0000CL-10
for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 10:20:11 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36854)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u693A-00006c-Rx
for 77725 <at> debbugs.gnu.org; Sat, 19 Apr 2025 10:20:09 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 60290440BE2;
Sat, 19 Apr 2025 10:20:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745072401;
bh=XDCtRtijfx7Q5VSV+x1Ibs7+OWhmVRWLTu0tGV0y8Rg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=XpNQnC2Lzy7uePEWDgzbUcGmYzAmfNCEjR6sNcb7KJVLniKKP8iiIYuJ2TQErY2FF
nQxUq5k5hma9VPttUWsaO9FRZXUF4CoMmJCWlhYevETmOiXMte5Bv6OfIyFxJpFFvR
gp0WRcuH6PfhN8lAcHcndctiwdB74k2xKXgsRJwHX4lhQ7CGpOuVEvvSbAeCPPIPi6
kdpSlqHkA27rf6TaUNjstnZQQsIiUri63APt+4FHRbBiDnBfPzDHnJ+W1q066JWpdn
BJ6I7DCKiMCPPyNgK/Kjb1wX3RV7GpXAiL3RRyT7uU44JNyvh1HlOl8T5kL36fpKoM
xyD9dpbrOfFgQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DFF3C440B0D;
Sat, 19 Apr 2025 10:20:01 -0400 (EDT)
Received: from pastel (104-195-239-180.cpe.teksavvy.com [104.195.239.180])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AA7CF12065C;
Sat, 19 Apr 2025 10:20:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
Message-ID: <jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
Date: Sat, 19 Apr 2025 10:20:00 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.023 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Regarding a possible merge in cl-lib, should cl-types.el be copied at
>> the end of cl-lib, after cl-macs is loaded?=A0 If I correctly understand
>> the logic of loading these libs ;-)
>
> I looked into this a bit more, and it turns out that cl-generic
> depends on cl-lib, so the code in cl-types.el that depends on
> cl-generic can't go in cl-lib. This concern the two definitions
> at the end of cl-types.el:
Yes, as you've seen, the placement can be tricky. There are bootstrap
constraints as well as "general design" desires, and they all kind
of pull in different directions.
I'll take a closer look and come back with a proposal.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Apr 2025 15:39:08 +0000
Resent-Message-ID: <handler.77725.B77725.17450771011405 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17450771011405
(code B ref 77725); Sat, 19 Apr 2025 15:39:08 +0000
Received: (at 77725) by debbugs.gnu.org; 19 Apr 2025 15:38:21 +0000
Received: from localhost ([127.0.0.1]:35579 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u6AGl-0000MJ-F0
for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 11:38:19 -0400
Received: from smtp-19.smtpout.orange.fr ([80.12.242.19]:47579
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u6AGZ-0000L4-Jo
for 77725 <at> debbugs.gnu.org; Sat, 19 Apr 2025 11:38:07 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 6AGRuh9R0iSFB6AGUuNr8k; Sat, 19 Apr 2025 17:38:01 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745077081;
bh=rXcLNMmyoMbNgiBZwPW7FGg8aOE4rshqAqa5i6IEF+Q=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=By4O3peP3zLEhjnkJOoZGU82L2em8ILeeJwMcNinj0dv0aIANBfmQyxLHRaEbIqmu
NN3BrlGyudinzqvjRaJx9oi8oeRxv/fpyi/JNW+7cVEQ0vk8yl7tynJHexGIKE8/JR
iHcMgWVuUfURRBl37OE4Y+V5TLSFy0faMvmzuVU9XQ8sR77qW3USrk4MMWh5IN/5My
pdgHLFoi304AHEzK3zl1GYjteNiWcRxYQ8uNI7RqMu70K6pfT84DhbqfD+wp2uT62C
WCvKvrmVd4H8EOeFg6BtOW/0HHSl5A33uczIIV2jwk+4nmonLxMc/ev8ENt2PvCT3F
baXsAKLcxa1Qg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sat, 19 Apr 2025 17:38:01 +0200
X-ME-IP: 90.112.40.65
Message-ID: <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
Date: Sat, 19 Apr 2025 17:37:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-19 16:20, Stefan Monnier wrote:
>>> Regarding a possible merge in cl-lib, should cl-types.el be copied at
>>> the end of cl-lib, after cl-macs is loaded? If I correctly understand
>>> the logic of loading these libs ;-)
>>
>> I looked into this a bit more, and it turns out that cl-generic
>> depends on cl-lib, so the code in cl-types.el that depends on
>> cl-generic can't go in cl-lib. This concern the two definitions
>> at the end of cl-types.el:
>
> Yes, as you've seen, the placement can be tricky. There are bootstrap
> constraints as well as "general design" desires, and they all kind
> of pull in different directions.
> I'll take a closer look and come back with a proposal.
Great. Thank you!
David
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Apr 2025 21:35:02 +0000
Resent-Message-ID: <handler.77725.B77725.17453576747631 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17453576747631
(code B ref 77725); Tue, 22 Apr 2025 21:35:02 +0000
Received: (at 77725) by debbugs.gnu.org; 22 Apr 2025 21:34:34 +0000
Received: from localhost ([127.0.0.1]:50295 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u7LGD-0001z0-3t
for submit <at> debbugs.gnu.org; Tue, 22 Apr 2025 17:34:34 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47960)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u7LGA-0001yl-EE
for 77725 <at> debbugs.gnu.org; Tue, 22 Apr 2025 17:34:31 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E8CA38061C;
Tue, 22 Apr 2025 17:34:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745357658;
bh=ybtJIr5wS0JC0z9iLo/hFvp8mdpsl/1EOCRQwSGOsRE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=KNQsAjy00bFW+zl9nZwjtVO3XSYbaWCok0BDb9BeKdRJQwS67aD2uwZPCp3k5c9bB
2G9n5X0NR+NoZ47yhZipxmPLsuWuCVTFzx+W/mIpVKIsNqzbftzN2Ovp2FxYtUlQ8T
eGZWZZpdrefpyIgcr0x7+Qxccah52+hVf/ziKsIeXY3mN72xqQBvLou3DcsN67AIGD
KNh8Uf8TkwNN63QMLqxDBd9oPtDgrgO5uzHR18p8BAWG+YC05hg59fTcqzYa1ol3Sl
EMzaMaqcNVT+tVrDzbjmJpak6CTjisImivq2yxltc/Z3E3bgZBPPi3TumBvxvRL1Ca
v2Q9vM/IXoodw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DE0FA80387;
Tue, 22 Apr 2025 17:34:18 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B731712022A;
Tue, 22 Apr 2025 17:34:18 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
Message-ID: <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
Date: Tue, 22 Apr 2025 17:34:17 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.221 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
PROLO_LEO1 0.1 Meta Catches all Leo drug variations so far
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
>> Yes, as you've seen, the placement can be tricky. There are bootstrap
>> constraints as well as "general design" desires, and they all kind
>> of pull in different directions.
>> I'll take a closer look and come back with a proposal.
> Great. Thank you!
Sorry for the delay, here's what I came up with.
I added a FIXME about the recursion-breaker which I have a feeling might
not work.
There's also some stylistic problems with the tests:
- We shouldn't test the return value of `cl-deftype`: I don't think it's
documented anywhere and I don't think it's good practice to pay
attention to the return value of declarations.
- They use `eval` too much.
Stefan
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=cl-types.patch
diff --git a/lisp/emacs-lisp/cl-extra.el b/lisp/emacs-lisp/cl-extra.el
index 6390d17a5b7..eb2ad605c8e 100644
--- a/lisp/emacs-lisp/cl-extra.el
+++ b/lisp/emacs-lisp/cl-extra.el
@@ -577,8 +577,8 @@ cl-subseq
,new)))))
(seq-subseq seq start end))
-;;; This isn't a defalias because autoloading defaliases doesn't work
-;;; very well.
+;; This isn't a defalias because autoloading defaliases doesn't work
+;; very well.
;;;###autoload
(defun cl-concatenate (type &rest sequences)
@@ -731,6 +731,213 @@ cl-prettyexpand
(cl-prettyprint form)
(message "")))
+;;; CL type defined via `deftype'.
+
+(defvar cl--type-list nil
+ "List of defined types to lookup for method dispatching.")
+
+;; FIXME: The `cl-deftype-handler' property should arguably be turned
+;; into a field of this struct (but it has performance and
+;; compatibility implications, so let's not make that change for now).
+(cl-defstruct
+ (cl-type-class
+ (:include cl--class)
+ (:noinline t)
+ (:constructor nil)
+ (:constructor cl--type-class-make
+ (name
+ docstring
+ parent-types
+ &aux (parents
+ (mapcar
+ (lambda (type)
+ (or (cl--find-class type)
+ (error "Unknown type: %S" type)))
+ parent-types))))
+ (:copier nil))
+ "Type descriptors for types defined by `cl-deftype'.")
+
+(defun cl--type-p (object)
+ "Return non-nil if OBJECT is a used defined type.
+That is, a type of class `cl-type-class'."
+ (and (symbolp object) (cl-type-class-p (cl--find-class object))))
+
+(defmacro cl--type-parents (name)
+ "Get parents of type with NAME.
+NAME is a symbol representing a type."
+ `(cl--class-allparents (cl--find-class ,name)))
+
+(defun cl--type-children (name)
+ "Get children of the type with NAME.
+NAME is a symbol representing a type.
+Return a possibly empty list of types."
+ (cl-check-type name (satisfies cl--type-p))
+ (let (children)
+ (dolist (elt cl--type-list)
+ (or (eq name elt)
+ (if (memq name (cl--type-parents elt))
+ (push elt children))))
+ children))
+
+;; Keep it for now, for testing.
+(defun cl--type-undefine (name)
+ "Remove the definitions of type with NAME.
+NAME is an unquoted symbol representing a type.
+Signal an error if other types inherit from NAME."
+ (declare-function cl-remprop "cl-extra" (symbol propname))
+ (cl-check-type name (satisfies cl--type-p))
+ (when-let* ((children (and (cl--type-p name)
+ (cl--type-children name))))
+ (error "Type has children: %S" children))
+ (cl-remprop name 'cl--class)
+ (cl-remprop name 'cl-deftype-handler)
+ (setq cl--type-list (delq name cl--type-list)))
+
+;;;###autoload
+(defun cl--type-deftype (name parents &optional docstring)
+ "Generalize type with NAME for method dispatching.
+PARENTS is a list of types NAME is a subtype of, or nil.
+DOCSTRING is an optional documentation string."
+ (let ((oldplist (copy-sequence (symbol-plist name))))
+ (condition-case err
+ (let* ((class (cl--find-class name))
+ (recorded (memq name cl--type-list)))
+ (if (null class)
+ (or (null recorded)
+ (error "Type generalized, but doesn't exist"))
+ (or recorded (error "Type exists, but not generalized"))
+ (or (cl-type-class-p class)
+ (error "Type in another class: %S" (type-of class))))
+ (if (memq name parents)
+ (error "Type in parents: %S" parents))
+ ;; Setup a type descriptor for NAME.
+ (setf (cl--find-class name)
+ (cl--type-class-make name docstring parents))
+ ;; `cl-types-of' iterates through all known types to collect
+ ;; all those an object belongs to, sorted from the most
+ ;; specific type to the more general type. So, keep the
+ ;; global list in this order.
+ (setq cl--type-list
+ (merge-ordered-lists
+ (mapcar (lambda (type)
+ (cl--class-allparents (cl--find-class type)))
+ (if recorded
+ cl--type-list
+ (cons name cl--type-list)))
+ (lambda (_) (error "Invalid dependency graph")))))
+ (error
+ ;; On error restore previous data.
+ (setf (symbol-plist name) oldplist)
+ (error (format "Define %S failed: %s"
+ name (error-message-string err)))))))
+
+(defvar cl--type-object (make-symbol "void"))
+;; Ensure each type satisfies `eql'.
+(defvar cl--type-unique (make-hash-table :test 'equal)
+ "Record an unique value of each type.")
+
+;; FIXME: `cl-types-of' CPU cost is proportional to the number of types
+;; defined with `cl-deftype', so the more popular it gets, the slower
+;; it becomes. And of course, the cost of each type check is
+;; unbounded, so a single "expensive" type can slow everything down
+;; further.
+;;
+;; The usual dispatch is
+;;
+;; (lambda (arg &rest args)
+;; (let ((f (gethash (cl-typeof arg) precomputed-methods-table)))
+;; (if f
+;; (apply f arg args)
+;; ;; Slow case when encountering a new type
+;; ...)))
+;;
+;; where often the most expensive part is `&rest' (which has to
+;; allocate a list for those remaining arguments),
+;;
+;; So we're talking about replacing
+;;
+;; &rest + cl-type-of + gethash + if + apply
+;;
+;; with a function that loops over N types, calling `cl-typep' on each
+;; one of them (`cl-typep' itself being a recursive function that
+;; basically interprets the type language). This is going to slow
+;; down dispatch very significantly for those generic functions that
+;; have a method that dispatches on a user defined type, compared to
+;; those that don't.
+;;
+;; A possible further improvement:
+;;
+;; - based on the PARENTS declaration, create a map from builtin-type
+;; to the set of cl-types that have that builtin-type among their
+;; parents. That presumes some PARENTS include some builtin-types,
+;; obviously otherwise the map will be trivial with all cl-types
+;; associated with the `t' "dummy parent". [ We could even go crazy
+;; and try and guess PARENTS when not provided, by analyzing the
+;; type's definition. ]
+;;
+;; - in `cl-types-of' start by calling `cl-type-of', then use the map
+;; to find which cl-types may need to be checked.
+;;
+;;;###autoload
+(defun cl-types-of (object)
+ "Return the types OBJECT belongs to.
+Return an unique list of types OBJECT belongs to, ordered from the
+most specific type to the most general."
+ ;; Ignore recursive call on the same OBJECT, which can legitimately
+ ;; occur when a parent type is checking whether an object's type is
+ ;; that of one of its children.
+ ;; FIXME: Does this even work? Won't `cl--type-object' be rebound to
+ ;; the other object before we get here? IOW wouldn't we need a list
+ ;; of objects that are in the process of being checked? And while
+ ;; returning nil breaks the recursion, won't it return a bogus result?
+ (unless (eq object cl--type-object)
+ (let ((cl--type-object object)
+ (found (list (cl--type-parents (cl-type-of object)))))
+ ;; Build a DAG of all types OBJECT belongs to.
+ (dolist (type cl--type-list)
+ (and
+ ;; Skip type not defined by `cl-deftype'.
+ (cl-type-class-p (cl--find-class type))
+ ;; If BAR is declared as a parent of FOO and `cl-types-of'
+ ;; has already decided that the value is of type FOO, then we
+ ;; already know BAR will be in the output anyway and there's
+ ;; no point testing BAR. So, skip type already selected as
+ ;; parent of another type, assuming that, most of the time,
+ ;; `assq' will be faster than `cl-typep'.
+ (null (assq type found))
+ ;; If OBJECT is of type, add type and parents to the DAG.
+ (cl-typep object type)
+ ;; (dolist (p (cl--type-parents type))
+ ;; (push (cl--type-parents p) found))
+ ;; Equivalent to the `dolist' above, but faster: avoid to
+ ;; recompute several lists of parents we already know.
+ (let ((pl (cl--type-parents type)))
+ (while pl
+ (push pl found)
+ (setq pl (cdr pl))))
+ ))
+ ;; Compute an ordered list of types from the collected DAG.
+ (setq found (merge-ordered-lists found))
+ ;; Return an unique value of this list of types, which is also
+ ;; the list of specifiers for this type.
+ (with-memoization (gethash found cl--type-unique)
+ found))))
+
+(cl-deftype extended-char () '(and character (not base-char)))
+
+;;;; Method dispatching
+
+(cl-generic-define-generalizer cl--type-generalizer
+ 20 ;; "typeof" < "cl-types-of" < "head" priority
+ (lambda (obj &rest _) `(cl-types-of ,obj))
+ (lambda (tag &rest _) (if (consp tag) tag)))
+
+(cl-defmethod cl-generic-generalizers :extra "cl-types-of" (type)
+ "Support for dispatch on types."
+ (if (cl--type-p type)
+ (list cl--type-generalizer)
+ (cl-call-next-method)))
+
;;; Integration into the online help system.
(eval-when-compile (require 'cl-macs)) ;Explicitly, for cl--find-class.
diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
index 8de45626bf0..af38f432e84 100644
--- a/lisp/emacs-lisp/cl-generic.el
+++ b/lisp/emacs-lisp/cl-generic.el
@@ -582,6 +582,7 @@ cl-defmethod
(,'declare-function ,name "")
;; We use #' to quote `name' so as to trigger an
;; obsolescence warning when applicable.
+ ;; FIXME: Eval `eql'and `head' thingies!
(cl-generic-define-method #',name ',(nreverse qualifiers) ',args
',call-con ,fun)))))
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index a966ec5eaf6..1bd3ab55519 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -3786,15 +3786,46 @@ cl--compiler-macro-get
;;;###autoload
(defmacro cl-deftype (name arglist &rest body)
"Define NAME as a new data type.
-The type name can then be used in `cl-typecase', `cl-check-type', etc."
+The type NAME can then be used in `cl-typecase', `cl-check-type', etc,
+and as argument type for dispatching generic function methods.
+
+ARGLIST is a Common Lisp argument list of the sort accepted by
+`cl-defmacro'. BODY forms are evaluated and should return a type
+specifier that is equivalent to the type (see the Info node `(cl) Type
+Predicates' in the GNU Emacs Common Lisp Emulation manual).
+
+If there is a `declare' form in BODY, the spec (parents PARENTS) is
+recognized to specify a list of types NAME is a subtype of. For
+instance:
+
+ (cl-deftype unsigned-byte (&optional bits)
+ \"Unsigned integer.\"
+ (list \\='integer 0 (if (eq bits \\='*) bits (1- (ash 1 bits)))))
+
+ (cl-deftype unsigned-8bits ()
+ \"Unsigned 8-bits integer.\"
+ (declare (parents unsigned-byte))
+ \\='(unsigned-byte 8))
+
+The list of PARENTS types determines the order of methods invocation,
+and missing PARENTS may cause incorrect ordering of methods, while
+extraneous PARENTS may cause use of extraneous methods."
(declare (debug cl-defmacro) (doc-string 3) (indent 2))
- `(cl-eval-when (compile load eval)
- (define-symbol-prop ',name 'cl-deftype-handler
- (cl-function (lambda (&cl-defs ('*) ,@arglist) ,@body)))))
-
-(cl-deftype extended-char () '(and character (not base-char)))
-;; Define fixnum so `cl-typep' recognize it and the type check emitted
-;; by `cl-the' is effective.
+ (pcase-let*
+ ((`(,decls . ,forms) (macroexp-parse-body body))
+ (docstring (if (stringp (car decls))
+ (car decls)
+ (cadr (assq :documentation decls))))
+ (parents (cdr (assq 'parents (cdr (assq 'declare decls))))))
+ (and parents arglist
+ (error "Parents specified, but arglist not empty"))
+ (if docstring (setq forms (cons docstring forms)))
+ `(cl-eval-when (compile load eval)
+ (cl--type-deftype ',name ',parents ,docstring)
+ (define-symbol-prop ',name 'cl-deftype-handler
+ (cl-function
+ (lambda (&cl-defs ('*) ,@arglist)
+ ,@forms))))))
;;; Additional functions that we can now define because we've defined
;;; `cl-defsubst' and `cl-typep'.
diff --git a/test/lisp/emacs-lisp/cl-extra-tests.el b/test/lisp/emacs-lisp/cl-extra-tests.el
index 20d1e532a6f..08198faf28c 100644
--- a/test/lisp/emacs-lisp/cl-extra-tests.el
+++ b/test/lisp/emacs-lisp/cl-extra-tests.el
@@ -348,4 +348,156 @@ cl-extra-test-tailp
(should (cl-tailp l l))
(should (not (cl-tailp '(4 5) l)))))
+(ert-deftest cl-types-test-1 ()
+ "Test types definition and cl-types-of."
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of (&optional m)
+ (let ((multiplep (if (eq m '*)
+ #'ignore
+ (lambda (n) (= 0 (% n m))))))
+ `(and integer (satisfies ,multiplep))))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of-2 ()
+ '(multiples-of 2))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of-3 ()
+ '(multiples-of 3))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of-4 ()
+ (declare (parents multiples-of-2))
+ '(and multiples-of-2 (multiples-of 4)))
+ t)))
+
+ ;; Test that (cl-types-of 4) is (multiples-of-4 multiples-of-2 ...)
+ ;; Test that (cl-types-of 6) is (multiples-of-3 multiples-of-2 ...)
+ ;; Test that (cl-types-of 12) is (multiples-of-4 multiples-of-3 multiples-of-2 ...)
+ (should
+ (equal
+ (cl-types-of 2)
+ '( multiples-of-2 fixnum integer number integer-or-marker
+ number-or-marker atom t)))
+
+ (should
+ (equal
+ (cl-types-of 4)
+ '( multiples-of-4 multiples-of-2 fixnum integer number
+ integer-or-marker number-or-marker atom t)
+ ))
+
+ (should
+ (equal
+ (cl-types-of 6)
+ '( multiples-of-3 multiples-of-2 fixnum integer number
+ integer-or-marker number-or-marker atom t)
+ ))
+
+ (should
+ (equal
+ (cl-types-of 12)
+ '( multiples-of-3 multiples-of-4 multiples-of-2 fixnum integer
+ number integer-or-marker number-or-marker atom t)
+ ))
+
+ (should
+ (equal
+ (cl-types-of 5)
+ '(fixnum integer number integer-or-marker number-or-marker atom t)
+ ))
+
+ ;; Cleanup
+ (mapc #'cl--type-undefine cl--type-list)
+
+ )
+
+(ert-deftest cl-types-test-2 ()
+ "Test types definition and dispatch."
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype unsigned-byte (&optional bits)
+ "Unsigned integer."
+ `(integer 0 ,(if (eq bits '*) bits (1- (ash 1 bits)))))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype unsigned-16bits ()
+ "Unsigned 16-bits integer."
+ (declare (parents unsigned-byte))
+ '(unsigned-byte 16))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype unsigned-8bits ()
+ "Unsigned 8-bits integer."
+ (declare (parents unsigned-16bits))
+ '(unsigned-byte 8))
+ t)))
+
+ ;; Invalid DAG error
+ (should-error
+ (eval
+ '(cl-deftype unsigned-16bits ()
+ "Unsigned 16-bits integer."
+ (declare (parents unsigned-8bits))
+ '(unsigned-byte 16))
+ t))
+
+ (eval
+ '(cl-defmethod my-foo ((_n unsigned-byte))
+ (format "unsigned"))
+ t)
+
+ (eval
+ '(cl-defmethod my-foo ((_n unsigned-16bits))
+ (format "unsigned 16bits - also %s"
+ (cl-call-next-method)))
+ t)
+
+ (eval
+ '(cl-defmethod my-foo ((_n unsigned-8bits))
+ (format "unsigned 8bits - also %s"
+ (cl-call-next-method)))
+ t)
+
+ (should
+ (equal
+ (my-foo 100)
+ "unsigned 8bits - also unsigned 16bits - also unsigned"
+ ))
+
+ (should
+ (equal
+ (my-foo 256)
+ "unsigned 16bits - also unsigned"
+ ))
+
+ (should
+ (equal
+ (my-foo most-positive-fixnum)
+ "unsigned"
+ ))
+ ;; Cleanup
+ (mapc #'cl--type-undefine cl--type-list)
+ )
+
;;; cl-extra-tests.el ends here
--=-=-=--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 23 Apr 2025 09:36:02 +0000
Resent-Message-ID: <handler.77725.B77725.174540091312144 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174540091312144
(code B ref 77725); Wed, 23 Apr 2025 09:36:02 +0000
Received: (at 77725) by debbugs.gnu.org; 23 Apr 2025 09:35:13 +0000
Received: from localhost ([127.0.0.1]:53336 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u7WVb-000398-B3
for submit <at> debbugs.gnu.org; Wed, 23 Apr 2025 05:35:13 -0400
Received: from smtp-72.smtpout.orange.fr ([80.12.242.72]:46023
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7WVW-000347-9l
for 77725 <at> debbugs.gnu.org; Wed, 23 Apr 2025 05:35:08 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 7WVIuRqNcX7PJ7WVLuWqiw; Wed, 23 Apr 2025 11:35:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745400904;
bh=RUGu11WNq0w12VutxXjkLD+CtZ9or4os/rG1FLSIWjE=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=O0BUAf8fpr7GUWmPwIFWcL1x1ExOWNkT/jy/Mdde6m4vxf6orQNg5i6pw2/mUaoY+
rJ0KeXHB5xt6M9i5EOkRXNeyjNdcBDJ/7eBdz/Me8AGKMhKTqf7PjL6H8rWw3a0AJN
gx90AgO9u1mbAw3crpMbuVW219iLv/74SIewIL8bW1s22TL0XgaacVHUpLhtTM0MVg
VzfYZxtsL3IK1aMWRdFLHs7ojSMAk0yggle29nPFCeBmzIFuDtspssu3efZyuppSuG
jbsQzMs7WYoeggcw3ebOL+dkOASZCs0oIcJApKsUysdLdDPUe1l6aDtOdNCaoRh5rC
iwiWa4bA9hE7w==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Wed, 23 Apr 2025 11:35:04 +0200
X-ME-IP: 90.112.40.65
Message-ID: <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
Date: Wed, 23 Apr 2025 11:34:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-22 23:34, Stefan Monnier wrote:
>>> Yes, as you've seen, the placement can be tricky. There are bootstrap
>>> constraints as well as "general design" desires, and they all kind
>>> of pull in different directions.
>>> I'll take a closer look and come back with a proposal.
>> Great. Thank you!
>
> Sorry for the delay, here's what I came up with.
No problem, we're in no rush and certainly have plenty of other things
to do in our life. Thank you very much for taking time to work on
this!
> I added a FIXME about the recursion-breaker which I have a feeling might
> not work.
I read your FIXME:
+ ;; FIXME: Does this even work? Won't `cl--type-object' be rebound to
+ ;; the other object before we get here? IOW wouldn't we need a list
+ ;; of objects that are in the process of being checked? And while
+ ;; returning nil breaks the recursion, won't it return a bogus result?
However, I don't understand why you think this might not work. I don't
see how `cl--type-object' can be rebound while `cl-types-of' is
running? Recursion can only occur when calling `cl-typep' to check the
type of `cl--type-object', and `cl-types-of' will immediately return
nil in that case. Did I miss something?
Regarding the bogus result, I chose to ignore types that will never
match, resulting in infinite recursion of `cl-types-of'. It's not
possible to signal an error here, as that would block subsequent types
that have no problem. Perhaps a warning message is missing when
recursion is detected on a type? It would probably be much better to
detect recursions during type definition and report an error at that
point. But I suspect that would be a lot of work.
Here is a test case with a recursion:
(cl-deftype T1 ()
"Root type.
Check if passed object is a subtype of T1. I.e., if T1 is present in
object type parents."
`(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
(cl-deftype T2 ()
"Recursive on checking for T1, never match."
(declare (parents T1))
`(and T1 (satisfies ,(lambda (o) (equal o '(T2))))))
(defgtype T3 ()
"Not recursive on T1."
(declare (parents T1))
`(satisfies ,(lambda (o) (equal o '(T3)))))
;; T2 will never match, because `cl-types-of' enters in an endless recursion
(cl-typep (list 'T2) 'T1)
=> nil
(cl-types-of (list 'T2))
=> (cons list sequence t)
;; T3 will match.
(cl-typep (list 'T3) 'T1)
=> (T1 cons list sequence t)
(cl-types-of (list 'T3))
=> (T3 T1 cons list sequence t)
> There's also some stylistic problems with the tests:
>
> - We shouldn't test the return value of `cl-deftype`: I don't think it's
> documented anywhere and I don't think it's good practice to pay
> attention to the return value of declarations.
You are certainly right. I just wanted to check that `cl-deftype'
didn't fail, but there is no `should-no-error'. Would it be better to
test for the presence of the type just defined in `cl--type-list'?
> - They use `eval` too much.
This is because `cl-deftype' is a macro and the doc string of
`ert-deftest' suggests to wrap macros in `(eval (quote ...))' to test
them.
But I must admit that my knowledge of ERT is very limited. Any
suggestions for improving the tests would be welcome.
David
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 23 Apr 2025 13:00:05 +0000
Resent-Message-ID: <handler.77725.B77725.174541318722883 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174541318722883
(code B ref 77725); Wed, 23 Apr 2025 13:00:05 +0000
Received: (at 77725) by debbugs.gnu.org; 23 Apr 2025 12:59:47 +0000
Received: from localhost ([127.0.0.1]:55530 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u7Zha-0005wp-AE
for submit <at> debbugs.gnu.org; Wed, 23 Apr 2025 08:59:47 -0400
Received: from smtp-73.smtpout.orange.fr ([80.12.242.73]:59937
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7ZhV-0005vx-TV
for 77725 <at> debbugs.gnu.org; Wed, 23 Apr 2025 08:59:43 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 7ZhIuwMuXCZIm7ZhLusStQ; Wed, 23 Apr 2025 14:59:40 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745413180;
bh=iFSNsv7QDhbS4JT/pM8OuoKkWGZLBw/n1nTXCcFtUEE=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=a7D9stwdBIe+E/CWTTfMNTOAmud978rQhVTrNnw8ElOwHqhGovOQWb2NNr86xyXwc
cjeee7o4kWMes2a9HDsXMQk2IRbkYi7XFUSCQI8YcFuSiE+GLU/4OXMlhGVTb0ZZWf
p079rp9mTAQh16Emm1ENl32OP2VAWRq28w8MbkcWtF5eAAZsQxOkTpZu0YehIm/1kF
V5i36ksxOLb39b5mDQBuSlfpHoHc7XL0ozDMJ63kGrexmbvsLrXst+GtONnsZnUwnl
cJ1QXqwysKCVcUumbLeGcdc2AakJzvylgVZmwQJTFXXbBYBTBW0i93WZ7xPqEHmcYn
8juSjfHzIWJyw==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Wed, 23 Apr 2025 14:59:40 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------WhsiHRnMr05b0GhdpVAPRinF"
Message-ID: <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
Date: Wed, 23 Apr 2025 14:59:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: David Ponce <da_vid@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------WhsiHRnMr05b0GhdpVAPRinF
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
While working with cl-types.el I discovered a nasty side effect
of byte compilation on the cl--type-list.
I can't explain what is going on :-(
Here is a recipe:
- run emacs -Q
- load cl-type.el (the last version previously attached)
- load cl-type-recipe.el (attached)
- In the scratch buffer eval cl--type-list. Result is expected:
(cons-cdr-foo cons-car-foo)
- Then open cl-type-recipe.el and byte-compile it with
M-x emacs-lisp-byte-compile
- Then eval again cl--type-list in the scratch buffer, and now the
result is something like this:
(#<symbol cons-cdr-foo at 158> #<symbol cons-car-foo at 46>)
Which completely breaks cl-types !
I hope you can shed some light on what is going on here.
Thanks!
--------------WhsiHRnMr05b0GhdpVAPRinF
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-type-recipe.el"
Content-Disposition: attachment; filename="cl-type-recipe.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgooY2wtZGVmdHlwZTIgY29ucy1jYXIt
Zm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2FyLiIKICBgKHNhdGlzZmllcyAsKGxh
bWJkYSAoeCkgKGVxIChjYXItc2FmZSB4KSAnZm9vKSkpKQoKKGNsLWRlZnR5cGUyIGNvbnMt
Y2RyLWZvbyAoKQogICJBIGNvbnMgd2l0aCBhIGBmb28nIGNkci4iCiAgYChzYXRpc2ZpZXMg
LChsYW1iZGEgKHgpIChlcSAoY2RyLXNhZmUgeCkgJ2ZvbykpKSkK
--------------WhsiHRnMr05b0GhdpVAPRinF--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 24 Apr 2025 11:45:01 +0000
Resent-Message-ID: <handler.77725.B77725.174549506329758 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174549506329758
(code B ref 77725); Thu, 24 Apr 2025 11:45:01 +0000
Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 11:44:23 +0000
Received: from localhost ([127.0.0.1]:36902 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u7v0A-0007ju-Kt
for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 07:44:23 -0400
Received: from smtp-30.smtpout.orange.fr ([80.12.242.30]:33103
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7v05-0007jP-M1
for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 07:44:18 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 7uzxu2U5kN5mI7v00uBNIe; Thu, 24 Apr 2025 13:44:15 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745495056;
bh=XRHHayeUZRcdxOyzjCVPrlAxFQBOHFaQiH7tEXNTBMM=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=amv6iIY1SrGqv28KXWQx0SeBG9dFpWZEypfZ36sc5pQiKyqLlzUK4WSLt4o/cw334
IVu+oyljOdsVHL2okp7EeBcryNO0xHtH7KQ/oQR89WziPtBWefkcW6bPoFcsmLE4Qg
zm+R4gJsh6+UZvXNrFDpqpi4KbXuzj11W6pXILQkS8Tr4Moi198/2HeMFcDS83EBW/
7nnTX5bKdODpy2tnCv0wZpCGownKm2l7Ne5Ij5RheRMPmXEyx7y8fwqapX0Dbng4Jo
PbEblbvrNMWtLXLHi775hddINd5FXPwrhb+HjQuXP7auusNg2iBo0FjuVz/MdB3ngY
kMxDtya7hLcSA==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Thu, 24 Apr 2025 13:44:16 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------qBlIzokXAVqaBLV6oMH0fVFq"
Message-ID: <2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN>
Date: Thu, 24 Apr 2025 13:44:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: David Ponce <da_vid@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------qBlIzokXAVqaBLV6oMH0fVFq
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2025-04-23 14:59, David Ponce wrote:
>
> While working with cl-types.el I discovered a nasty side effect
> of byte compilation on the cl--type-list.
>
> I can't explain what is going on :-(
>
> Here is a recipe:
>
> - run emacs -Q
>
> - load cl-type.el (the last version previously attached)
>
> - load cl-type-recipe.el (attached)
>
> - In the scratch buffer eval cl--type-list. Result is expected:
>
> (cons-cdr-foo cons-car-foo)
>
> - Then open cl-type-recipe.el and byte-compile it with
> M-x emacs-lisp-byte-compile
>
> - Then eval again cl--type-list in the scratch buffer, and now the
> result is something like this:
>
> (#<symbol cons-cdr-foo at 158> #<symbol cons-car-foo at 46>)
>
> Which completely breaks cl-types !
>
> I hope you can shed some light on what is going on here.
>
> Thanks!
>
It seems the side effect is more general than just with cl-type.el.
I attached cl-type-recipe2.el, another simple recipe to illustrate with
current `cl-deftype'.
- Run emacs -Q and load cl-type-recipe2.el.
- Then in the scratch buffer eval:
(symbol-plist 'cons-car-foo)
=> (cl-deftype-handler #[nil ((list 'satisfies #'(lambda (x) (eq (car-safe x) 'foo)))) (t) nil "A cons with a `foo' car."])
- Then open cl-type-recipe2.el and M-x emacs-lisp-byte-compile
- Then in the scratch buffer eval again:
(symbol-plist 'cons-car-foo)
=> (cl-deftype-handler #[nil (`(#<symbol satisfies at 113> ,(#<symbol lambda at 125> (x) (#<symbol eq at 137> (#<symbol car-safe at 141> #<symbol x at 150>) '#<symbol foo at 154>)))) (t) nil "A cons with a `foo' car."])
And, of course:
(cl-typep '(foo) 'cons-car-foo)
=> (invalid-function #<symbol lambda at 125>)
Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect.
Hope it will help.
David
--------------qBlIzokXAVqaBLV6oMH0fVFq
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-type-recipe2.el"
Content-Disposition: attachment; filename="cl-type-recipe2.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgoocmVxdWlyZSAnY2wtbGliKQoKKGNs
LWRlZnR5cGUgY29ucy1jYXItZm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2FyLiIK
ICBgKHNhdGlzZmllcyAsKGxhbWJkYSAoeCkgKGVxIChjYXItc2FmZSB4KSAnZm9vKSkpKQoK
KGNsLWRlZnR5cGUgY29ucy1jZHItZm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2Ry
LiIKICBgKHNhdGlzZmllcyAsKGxhbWJkYSAoeCkgKGVxIChjZHItc2FmZSB4KSAnZm9vKSkp
KQo=
--------------qBlIzokXAVqaBLV6oMH0fVFq--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 24 Apr 2025 16:35:01 +0000
Resent-Message-ID: <handler.77725.B77725.17455124635390 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17455124635390
(code B ref 77725); Thu, 24 Apr 2025 16:35:01 +0000
Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 16:34:23 +0000
Received: from localhost ([127.0.0.1]:40618 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u7zWo-0001Op-9j
for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 12:34:22 -0400
Received: from smtp-74.smtpout.orange.fr ([80.12.242.74]:44693
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7zWh-0001OW-Fl
for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 12:34:18 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 7zWZu5VowCZIm7zWcuoHV9; Thu, 24 Apr 2025 18:34:13 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745512453;
bh=Vtzh+6FqS8meQ+ESlHUz7a7AskghZHPvCkjCuHXbfzI=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=pE5QZoEw2ZR6cvMPU5A5TsUhBlDdgK2/mC/Xxy8M5jlT+6/M1AYjO+oTu0dKH07Pi
mH7rt3Ffiev4szfzeLEbjSz4u3Lz4ARkYSRFu5b1+DfAgsTm/6jy+Djvqq03tbU+cp
6+fqj/8RGcxY4mLr1Nu7vRkopzlI7iunCB07/SIC64dlhbmsPqTRXdpN76Zuq41hs7
h0dXNZx36xnopGK1YNFo3r+WmVrCzZ3PjfPEONWFZAYd5TCKtES7ODvRe+yP9gczNB
296ky+0DEC7ztCzLgrOtIZ0oMAHpPIMtDfGn+ytbqtF5SDVa+MncfdY5Fuas6eUmkh
i2NW/Z03yt3uw==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Thu, 24 Apr 2025 18:34:13 +0200
X-ME-IP: 90.112.40.65
Message-ID: <85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN>
Date: Thu, 24 Apr 2025 18:34:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: David Ponce <da_vid@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
<2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-24 13:44, David Ponce wrote:
> On 2025-04-23 14:59, David Ponce wrote:
>>
>> While working with cl-types.el I discovered a nasty side effect
>> of byte compilation on the cl--type-list.
>>
>> I can't explain what is going on :-(
>>
>> Here is a recipe:
>>
>> - run emacs -Q
>>
>> - load cl-type.el (the last version previously attached)
>>
>> - load cl-type-recipe.el (attached)
>>
>> - In the scratch buffer eval cl--type-list. Result is expected:
>>
>> (cons-cdr-foo cons-car-foo)
>>
>> - Then open cl-type-recipe.el and byte-compile it with
>> M-x emacs-lisp-byte-compile
>>
>> - Then eval again cl--type-list in the scratch buffer, and now the
>> result is something like this:
>>
>> (#<symbol cons-cdr-foo at 158> #<symbol cons-car-foo at 46>)
>>
>> Which completely breaks cl-types !
>>
>> I hope you can shed some light on what is going on here.
>>
>> Thanks!
>>
>
> It seems the side effect is more general than just with cl-type.el.
>
> I attached cl-type-recipe2.el, another simple recipe to illustrate with
> current `cl-deftype'.
>
> - Run emacs -Q and load cl-type-recipe2.el.
> - Then in the scratch buffer eval:
>
> (symbol-plist 'cons-car-foo)
> => (cl-deftype-handler #[nil ((list 'satisfies #'(lambda (x) (eq (car-safe x) 'foo)))) (t) nil "A cons with a `foo' car."])
>
> - Then open cl-type-recipe2.el and M-x emacs-lisp-byte-compile
>
> - Then in the scratch buffer eval again:
>
> (symbol-plist 'cons-car-foo)
> => (cl-deftype-handler #[nil (`(#<symbol satisfies at 113> ,(#<symbol lambda at 125> (x) (#<symbol eq at 137> (#<symbol car-safe at 141> #<symbol x at 150>) '#<symbol foo at 154>)))) (t) nil "A cons with a `foo' car."])
>
> And, of course:
>
> (cl-typep '(foo) 'cons-car-foo)
> => (invalid-function #<symbol lambda at 125>)
>
> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect.
>
> Hope it will help.
>
> David
Another information which could be useful: if I replace (cl-eval-when (compile load eval) ...)
by (eval-and-compile ...) in the definition of `cl-deftype', there is no side effect
of the byte-compilation on the current definition.
What I don't know is if the two forms are equivalent.
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 24 Apr 2025 19:39:02 +0000
Resent-Message-ID: <handler.77725.B77725.174552353116085 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174552353116085
(code B ref 77725); Thu, 24 Apr 2025 19:39:02 +0000
Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 19:38:51 +0000
Received: from localhost ([127.0.0.1]:41437 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u82PK-0004BH-S4
for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:38:51 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15694)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u82PH-0004Al-Sa
for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:38:50 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 342C08087F;
Thu, 24 Apr 2025 15:38:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745523520;
bh=kbhyl4Rfq2SIOs6K3nHnsg+Q8NFCqa/VY+6Gahg13d0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=mf3jhvxPR/pvZaLw5dpVyMocLkMB9Iw+Z4Q+vrempDE4JAiKJNq7S6ruKuWEq0Uxs
Ai4wdurmsyCPeIkcbFKMaCBGejm4ru5lRb63IVed4BN5L8hrxjgHg2uIL24Kk0UUQ7
2AIoTAk4MPAEK77lzg4amssoYax7BfE+s/H80zfJWH9Mwa/KdOkn5gaW7ig2nWOiBB
b61FAxenE1YANXB0xipWesAwlhjH+2/PAUzxovQFHzRIzQ2tEWyJjaIYifJ1KBzUSI
mvIWQCXX7mhLcRNrjxuziFNdnDgT831dyvr5tedjLBZBMSaaGd1zQs3hk3vwK84SbL
sTEYr7HySUh3A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CAD5C802A2;
Thu, 24 Apr 2025 15:38:40 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A38B5120568;
Thu, 24 Apr 2025 15:38:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
Message-ID: <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
Date: Thu, 24 Apr 2025 15:38:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.169 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Here is a test case with a recursion:
>
> (cl-deftype T1 ()
> "Root type.
> Check if passed object is a subtype of T1. I.e., if T1 is present in
> object type parents."
> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
Hmm... I can see that it could be handy if you don't know how to
characterize type T1 other than as the "sum" of its subtypes.
But this seems rather circular. Have you seen such things out in
the wild?
More importantly, with your circularity-breaking approach, if `gtype-of`
(aka `cl-types-of`) happens to look at T1 first, that check will
immediately return nil, so `cl-types-of` may decide "Oh, I just
discovered this is not a T1, so I can skip checking all the subtypes of
T1". So, the cycle is broken, but the output is wrong.
The need for multiple object would be for cases like:
(cl-deftype car-foo ()
"Car-Foo type.
Check if passed object has a subtype of FOO as car."
`(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
but I guess this can inf-loop only if we follow a cycle in the object
(e.g. say if o =3D=3D (car (car (car o)))).
> (cl-deftype T2 ()
> "Recursive on checking for T1, never match."
> (declare (parents T1))
> `(and T1 (satisfies ,(lambda (o) (equal o '(T2))))))
Is this definition meaningful with the above definition of T1?
I don't think it's well-founded.
> (defgtype T3 ()
> "Not recursive on T1."
> (declare (parents T1))
> `(satisfies ,(lambda (o) (equal o '(T3)))))
>
> ;; T2 will never match, because `cl-types-of' enters in an endless recurs=
ion
> (cl-typep (list 'T2) 'T1)
> =3D> nil
This is both right and wrong: we could return t and that would be
equally valid.
> (cl-types-of (list 'T2))
> =3D> (cons list sequence t)
And here (T2 T1 cons list sequence t) would also be equally valid.
>> There's also some stylistic problems with the tests:
>> - We shouldn't test the return value of `cl-deftype`: I don't think it's
>> documented anywhere and I don't think it's good practice to pay
>> attention to the return value of declarations.
> You are certainly right. I just wanted to check that `cl-deftype'
> didn't fail, but there is no `should-no-error'. Would it be better to
> test for the presence of the type just defined in `cl--type-list'?
I'd just move the `cl-deftype` calls out of the tests and presume that if
they signal an error we'll see it.
>> - They use `eval` too much.
> This is because `cl-deftype' is a macro and the doc string of
> `ert-deftest' suggests to wrap macros in `(eval (quote ...))' to test
> them.
That's only when you specifically need to test the effect of the
macro-expansion itself, rather than test the result of running the
macro-expanded code. It's rarely needed IME. An example would be to
detect when a macro-expansion emits a warning.
Also, by using this `eval+quote` you can't test the macro in the way
it's usually used (where it's macro-expanded once during compilation and
then its result is run in another Emacs session) so you may miss bugs
such as when the macro's expansion performs a side-effect (like add
something to a list) which the expanded code expects to have happened
(but this will have happened during compilation, so the element may not
be in the list any more when the code is finally executed).
IOW, I disagree with the docstring. =F0=9F=99=81
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 24 Apr 2025 19:45:03 +0000
Resent-Message-ID: <handler.77725.B77725.174552389017467 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174552389017467
(code B ref 77725); Thu, 24 Apr 2025 19:45:03 +0000
Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 19:44:50 +0000
Received: from localhost ([127.0.0.1]:41477 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u82V7-0004Xf-WA
for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:44:50 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63872)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u82V4-0004XA-Kt
for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:44:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 02DB710013E;
Thu, 24 Apr 2025 15:44:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745523880;
bh=Sr53QluRaFPrXTG2Uer5tuUMKYlu+W3Ue7nAisRgpsA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=VQDuaEWx8LR67hv0MY1OrkydLZD6jC2x4iwrl9kqcouR33He23FcNx5FQXkerz44u
zpaUOTkHf+8f/dBaWfNfes7TUnBgapMly8LPf0JceWOg2TSivhLwyPjMN/dBOLa5P8
5T0DyolR27aXiPb3uLYyZq3AyA6Do/kb8T85RH6rgbBNs03ck15GRs1Rih690plEV1
AnUq33yx55y36qEHstQi/7jiqWBqX1cceeGEyBtujelwjBpCIz6/ol0Ch7pklLbIWb
Ps9HUOP5hdO4rW9yeJMx9jcspPeN6Y6y5939wGRuLEOHmcfPnTcphSufJS4GDjOUhd
On0CdHnBJWcag==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 604C0100034;
Thu, 24 Apr 2025 15:44:40 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 45B0E12051F;
Thu, 24 Apr 2025 15:44:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN>
Message-ID: <jwvbjsl9wky.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
<2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN>
<85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN>
Date: Thu, 24 Apr 2025 15:44:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.204 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Another information which could be useful: if I replace (cl-eval-when
> (compile load eval) ...) by (eval-and-compile ...) in the definition
> of `cl-deftype', there is no side effect of the byte-compilation on
> the current definition.
It looks like this is a bug in `cl-eval-when` introduced when Alan added
"symbol with positions" for better error reporting.
Could you make it a separate bug-report?
> What I don't know is if the two forms are equivalent.
Obviously they don't do quite the same thing, but AFAIK they *should*
behave the same, so I'd use `eval-and-compile`.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Apr 2025 09:02:02 +0000
Resent-Message-ID: <handler.77725.B77725.174557168426595 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174557168426595
(code B ref 77725); Fri, 25 Apr 2025 09:02:02 +0000
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 09:01:24 +0000
Received: from localhost ([127.0.0.1]:47184 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8Evz-0006ur-Pi
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:01:24 -0400
Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:44901
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8Evu-0006uR-O3
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:01:21 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 8EvnuxSy2OaHY8EvruW8LY; Fri, 25 Apr 2025 11:01:16 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745571676;
bh=8XW2fgSCO82sqeYNL1E3IJKaOl2CMKUURjQp7eQA3RU=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=I9hG1nMZV7X8c8MwOHyss2dSa4SrLNxMcnTa05HOcUB022DEFIlXQtvCHYj6O77Le
/fUuQGFdv2jwRMhscqISvwQKxvGx9GUZ3reeyKecVEOXsOjOt0LDXQIgwnGPZVZ42z
SFbAtI6KiLp6mBAYqvM73c5m7ywB7J6JNg9AXakYpxq+/8Gq65rrQYhmwZ0zXF4efA
WMqTPcaDauCtktLZhbdQHQKJbyCpizE7inKvkPfrCrwFXJ/2zOt1RZ7VsQCFbwIY25
CzeX2D6NLL4uQBta+qjcIc42MZzJztlJTKW4mSxWc71spZa7sbj9W98upEGetv0xws
gfNy7EOe+czPA==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 25 Apr 2025 11:01:16 +0200
X-ME-IP: 90.112.40.65
Message-ID: <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
Date: Fri, 25 Apr 2025 11:01:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-24 21:38, Stefan Monnier wrote:
>> Here is a test case with a recursion:
>>
>> (cl-deftype T1 ()
>> "Root type.
>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>> object type parents."
>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>
> Hmm... I can see that it could be handy if you don't know how to
> characterize type T1 other than as the "sum" of its subtypes.
> But this seems rather circular. Have you seen such things out in
> the wild?
I am using a such "abstract" type in one of my library for exactly
this: "characterize type T1 other than as the "sum" of its subtypes."
> More importantly, with your circularity-breaking approach, if `gtype-of`
> (aka `cl-types-of`) happens to look at T1 first, that check will
> immediately return nil, so `cl-types-of` may decide "Oh, I just
> discovered this is not a T1, so I can skip checking all the subtypes of
> T1". So, the cycle is broken, but the output is wrong.
Look at T1 first should be possible only if T1 is alone, without any
subtype defined. This is why I call T1 an "abstract" type. And as such
it is normal that no object will belong to it directly. For an object to
belong to T1 it must first belong to one of its "concrete" subtype (with a
builtin Emacs type in parents). And in this case it is guaranteed that
subtypes will appear before T1 in the list of defined types to check.
So, no recursion on T1 when subtypes exist.
Did I miss something?
>
> The need for multiple object would be for cases like:
>
> (cl-deftype car-foo ()
> "Car-Foo type.
> Check if passed object has a subtype of FOO as car."
> `(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
>
> but I guess this can inf-loop only if we follow a cycle in the object
> (e.g. say if o == (car (car (car o)))).
Not sure to understand what you mean by "need for multiple object", I am sorry.
I tries this, and, for me it works as expected:
(cl-deftype car-foo ()
"Car-Foo type.
Check if passed object has a subtype of FOO as car."
`(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
(cl-deftype FOO ()
`(or (and symbol (satisfies ,(lambda (o) (eq o 'FOO))))
car-foo))
(cl-types-of 'FOO)
=> FOO symbol atom t)
(cl-types-of '(FOO))
=> (FOO car-foo cons list sequence t)
(cl-types-of '(((((FOO))))))
=> (FOO car-foo cons list sequence t)
However, in the last case, cl-types-of is entered 95 times!
This makes me think that errors that might occur when calling
`cl-typep' should be handled in `cl-types-of' to prevent an
incorrect definition from impacting method dispatching on types
correctly defined.
WDYT?
>
>> (cl-deftype T2 ()
>> "Recursive on checking for T1, never match."
>> (declare (parents T1))
>> `(and T1 (satisfies ,(lambda (o) (equal o '(T2))))))
>
> Is this definition meaningful with the above definition of T1?
> I don't think it's well-founded.
Correct. It was just a "bad" example. The correct definition is T3.
>> (defgtype T3 ()
>> "Not recursive on T1."
>> (declare (parents T1))
>> `(satisfies ,(lambda (o) (equal o '(T3)))))
>>
>> ;; T2 will never match, because `cl-types-of' enters in an endless recursion
>> (cl-typep (list 'T2) 'T1)
>> => nil
>
> This is both right and wrong: we could return t and that would be
> equally valid.
>
>> (cl-types-of (list 'T2))
>> => (cons list sequence t)
>
> And here (T2 T1 cons list sequence t) would also be equally valid.
Sorry, you lost me here. As I understand it, a type whose definition
enter in an endless recursion is not valid, and should never match?
>
>>> There's also some stylistic problems with the tests:
>>> - We shouldn't test the return value of `cl-deftype`: I don't think it's
>>> documented anywhere and I don't think it's good practice to pay
>>> attention to the return value of declarations.
>> You are certainly right. I just wanted to check that `cl-deftype'
>> didn't fail, but there is no `should-no-error'. Would it be better to
>> test for the presence of the type just defined in `cl--type-list'?
>
> I'd just move the `cl-deftype` calls out of the tests and presume that if
> they signal an error we'll see it.
The problem with this approach is that it is difficult to isolate and cleanup
the definitions needed for test-1 from those needed for test-2. Also the result
will depends on the order of the cl-deftype for test-1 and test-2, because these
definitions will be effective outside of test-1 and test-2.
But maybe it's not so important after all. I'll try to reformulate the tests this way.
>
>>> - They use `eval` too much.
>> This is because `cl-deftype' is a macro and the doc string of
>> `ert-deftest' suggests to wrap macros in `(eval (quote ...))' to test
>> them.
>
> That's only when you specifically need to test the effect of the
> macro-expansion itself, rather than test the result of running the
> macro-expanded code. It's rarely needed IME. An example would be to
> detect when a macro-expansion emits a warning.
>
> Also, by using this `eval+quote` you can't test the macro in the way
> it's usually used (where it's macro-expanded once during compilation and
> then its result is run in another Emacs session) so you may miss bugs
> such as when the macro's expansion performs a side-effect (like add
> something to a list) which the expanded code expects to have happened
> (but this will have happened during compilation, so the element may not
> be in the list any more when the code is finally executed).
>
> IOW, I disagree with the docstring. 🙁
I understand.
Thanks
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Apr 2025 09:03:02 +0000
Resent-Message-ID: <handler.77725.B77725.174557175026791 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174557175026791
(code B ref 77725); Fri, 25 Apr 2025 09:03:02 +0000
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 09:02:30 +0000
Received: from localhost ([127.0.0.1]:47193 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8Ex3-0006y2-SU
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:02:30 -0400
Received: from smtp-82.smtpout.orange.fr ([80.12.242.82]:47251
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8Ex1-0006xs-NT
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:02:28 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 8Ewuuwwmpvf4p8Ewxugyth; Fri, 25 Apr 2025 11:02:26 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745571746;
bh=GT01lSjYxR7CR65lUt+9IH7gtM9JKIIe1BnM/8RmN9g=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=JfbgNgU+J4+cB5zSdCehV3CfbjnpNcbH5JW354uS4BXG5fqXReImw/GjlkdA33lEM
tnfVY+47fRc3aaHelOMG2ldojtrHZ0uAt0MM4TFHubC46NB360fxsXAsOqIfVf0rlh
rCywJVsDLihZIQC/HO2aHKot8g2gVUpNUKqPI7MNdZo9FXRwl/ykqv7XJEtIF0uUiS
NzY+5RKnELLCQROJLDlv8VBqiS1h3nQIA6AgufWbNvv9MQTGZLvvBzxYjTyfL2tNhy
nrHNS4Ct9Lb0szal73arrvR4XGHIEEjMt8OuTe2+Frkee6TK2iupmU0D+EKtu1JfO9
BebuCgKVrok9Q==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 25 Apr 2025 11:02:26 +0200
X-ME-IP: 90.112.40.65
Message-ID: <d9f0efa0-b3c1-4bbc-a8ec-9c5d394a7c9a@HIDDEN>
Date: Fri, 25 Apr 2025 11:02:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
<2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN>
<85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN>
<jwvbjsl9wky.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvbjsl9wky.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-24 21:44, Stefan Monnier wrote:
>> Another information which could be useful: if I replace (cl-eval-when
>> (compile load eval) ...) by (eval-and-compile ...) in the definition
>> of `cl-deftype', there is no side effect of the byte-compilation on
>> the current definition.
>
> It looks like this is a bug in `cl-eval-when` introduced when Alan added
> "symbol with positions" for better error reporting.
>
> Could you make it a separate bug-report?
Done. Bug#78056
>
>> What I don't know is if the two forms are equivalent.
>
> Obviously they don't do quite the same thing, but AFAIK they *should*
> behave the same, so I'd use `eval-and-compile`.
>
Ok, done.
Thank you!
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Apr 2025 18:08:01 +0000
Resent-Message-ID: <handler.77725.B77725.174560443614323 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174560443614323
(code B ref 77725); Fri, 25 Apr 2025 18:08:01 +0000
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 18:07:16 +0000
Received: from localhost ([127.0.0.1]:52624 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8NSF-0003iw-De
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 14:07:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1059)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u8NSC-0003ia-V6
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 14:07:13 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3696480911;
Fri, 25 Apr 2025 14:07:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745604425;
bh=Fw8Q96Ppzq/xzBXkl35O1/dysQboZnEwoUCbf4o8sYs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=equhsCUrn84kPXmRoyQzV+SBQ9qd5DGEF3o8Q6FwwqzeHgdtFcGdsfOvISpycmdY4
AG9zscRTESQbYwb423jjJBQS6dpcOZsRFQ4kS9aAeP4wloHMRE05mitmf44pVV03pY
DlHOYQSr9S7BXDlG6AgM8tDxo5Gw+DRBLYAu20Fi0b2typNHokSMjf+uiGOXYBNV5H
lCQ++1ZCjkU4L5cQq1+3QDg+sj+KuThW9Sep/NaY4rGGUy++rCmx0Ec79wrxN2WWIB
5RZqW7hmxvnt9K8P484mQuV1BeASFlh2R9sk+B7ABPegmXVzXyCQb80KOYYcHm6Bws
JikSSjnL/OR3g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0BB9E80860;
Fri, 25 Apr 2025 14:07:05 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EFFC01201A9;
Fri, 25 Apr 2025 14:07:04 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
Message-ID: <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
Date: Fri, 25 Apr 2025 14:07:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.202 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> (cl-deftype T1 ()
>>> "Root type.
>>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>>> object type parents."
>>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>> Hmm... I can see that it could be handy if you don't know how to
>> characterize type T1 other than as the "sum" of its subtypes.
>> But this seems rather circular. Have you seen such things out in
>> the wild?
> I am using a such "abstract" type in one of my library for exactly
> this: "characterize type T1 other than as the "sum" of its subtypes."
[ FWIW, this definition makes your type-test quite costly since it will
test more or less each and every type defined with `cl-deftype`.
You'd be better served with a more targeted test which keeps track of
the children of T1 so it can then do something like
(cl-some (lambda (child) (cl-typep o child)) my-children)
This way the performance is not affected by random other unrelated types.
But, yes, that begs the question of how to keep track of the
children, e.g. how to be told when a child needs to be added/removed
to/from `my-children`. ]
>> More importantly, with your circularity-breaking approach, if `gtype-of`
>> (aka `cl-types-of`) happens to look at T1 first, that check will
>> immediately return nil, so `cl-types-of` may decide "Oh, I just
>> discovered this is not a T1, so I can skip checking all the subtypes of
>> T1". So, the cycle is broken, but the output is wrong.
>
> Look at T1 first should be possible only if T1 is alone, without any
[...]
Agreed.
> Did I miss something?
What you missed (because I didn't make it clear) is that I was talking
about an incorrect behavior of your circularity-breaking approach, when
coupled with *another* algorithm than the one you currently use to
collect the set of types to return in `cl-types-of`.
>> The need for multiple object would be for cases like:
>> (cl-deftype car-foo ()
>> "Car-Foo type.
>> Check if passed object has a subtype of FOO as car."
>> `(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
>> but I guess this can inf-loop only if we follow a cycle in the object
>> (e.g. say if o == (car (car (car o)))).
>
> Not sure to understand what you mean by "need for multiple object", I am sorry.
>
> I tries this, and, for me it works as expected:
>
> (cl-deftype car-foo ()
> "Car-Foo type.
> Check if passed object has a subtype of FOO as car."
> `(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
>
> (cl-deftype FOO ()
> `(or (and symbol (satisfies ,(lambda (o) (eq o 'FOO))))
> car-foo))
>
> (cl-types-of 'FOO)
> => FOO symbol atom t)
>
> (cl-types-of '(FOO))
> => (FOO car-foo cons list sequence t)
>
> (cl-types-of '(((((FOO))))))
> => (FOO car-foo cons list sequence t)
Don't test it with '(((((FOO))))) because that's not a case where
`o == (car (car (car o)))` You need something like
(let ((o (list nil nil)))
(setq o (list (list (list o))))
(cl-types-of o))
As I implied, this is probably not too serious.
> This makes me think that errors that might occur when calling
> `cl-typep' should be handled in `cl-types-of' to prevent an
> incorrect definition from impacting method dispatching on types
> correctly defined.
> WDYT?
Maybe. I'd tend to think that `cl-typep` should never error, so if it
ever does (which would indicate a bug in some `cl-deftype`), we wouldn't
want to hide that error.
>>> ;; T2 will never match, because `cl-types-of' enters in an endless recursion
>>> (cl-typep (list 'T2) 'T1)
>>> => nil
>> This is both right and wrong: we could return t and that would be
>> equally valid.
>>
>>> (cl-types-of (list 'T2))
>>> => (cons list sequence t)
>> And here (T2 T1 cons list sequence t) would also be equally valid.
>
> Sorry, you lost me here. As I understand it, a type whose definition
> enter in an endless recursion is not valid, and should never match?
It depends on whether you define your types inductively or co-inductively.
IOW, do you define the type by starting with the "empty set" and then
adding new elements to it until there's nothing more to add, or do you
define it by starting with a "total set" that contains everything and
then remove elements from it until you've removed everything that
doesn't belong there.
Another way to look at it: there's nothing in your definition of T2 that
says that the list `(T2)` should *not* be an element of that type.
For recursive values, in order to break circularity, it is common to
check whether a value satisfies a constraint by adding "yes it does" as
a temporary assumption while performing the check, so as to break the
cycle when we get to a nested occurrence of that object.
If we use the same approach here, the T2 test will say that `(T2)` is
indeed of type T2.
>>>> There's also some stylistic problems with the tests:
>>>> - We shouldn't test the return value of `cl-deftype`: I don't think it's
>>>> documented anywhere and I don't think it's good practice to pay
>>>> attention to the return value of declarations.
>>> You are certainly right. I just wanted to check that `cl-deftype'
>>> didn't fail, but there is no `should-no-error'. Would it be better to
>>> test for the presence of the type just defined in `cl--type-list'?
>> I'd just move the `cl-deftype` calls out of the tests and presume that if
>> they signal an error we'll see it.
>
> The problem with this approach is that it is difficult to isolate and cleanup
> the definitions needed for test-1 from those needed for test-2. Also the result
> will depends on the order of the cl-deftype for test-1 and test-2, because these
> definitions will be effective outside of test-1 and test-2.
>
> But maybe it's not so important after all. I'll try to reformulate the tests this way.
In the worst case, you can duplicate the definitions (with different names).
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Apr 2025 19:38:01 +0000
Resent-Message-ID: <handler.77725.B77725.17456098688872 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17456098688872
(code B ref 77725); Fri, 25 Apr 2025 19:38:01 +0000
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 19:37:48 +0000
Received: from localhost ([127.0.0.1]:53330 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8Ors-0002J2-2y
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 15:37:48 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60612)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u8Orp-0002Ib-O6
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 15:37:46 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EE9CF8061C;
Fri, 25 Apr 2025 15:37:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745609859;
bh=qw6jisVQqd0a08K0OrRav6WyGlbMiewCjrUMZTuqDtA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=nl/FxiFzN0TY+PR8nzN6ZeFg9pjWxGRfU6fqhfDm12N0/FH5dhCxkYZ6pNq4P9wEf
ghvYx0rG9lS9El9tz23mI7qF+lVsFghfAic6Aq56N2DvkAOeYSP2nvnyFKtGep8255
Z9vAotoQfnYy6buksJ15/qOAJxzRcnKDh0oR8IXbcP1TSzCmskQGjQQC6wp6VQr/x1
UGIhV1Yp+gqAlIy2SH6x1InfI1Kx3WbbKOCjIDjuVlvQT91cuy6lIV6S4DLQMI4acr
set/pq8qIAX3XZSsehXeEBjj8IaQ0qtEES7wFuOpBmp/G1iyiek3l2d2kiU/U8WNHO
DmdXU5V9BvYkg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 28301806EF;
Fri, 25 Apr 2025 15:37:39 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 13996120497;
Fri, 25 Apr 2025 15:37:39 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwv7c38avsu.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Date: Fri, 25 Apr 2025 15:37:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.202 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
[ Just tooting my horn, nothing to see. ]
>> Here is a test case with a recursion:
>>
>> (cl-deftype T1 ()
>> "Root type.
>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>> object type parents."
>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>
> Hmm... I can see that it could be handy if you don't know how to
> characterize type T1 other than as the "sum" of its subtypes.
> But this seems rather circular. Have you seen such things out in
> the wild?
BTW, this form of circularity is called an *impredicative* definition:
the above definition does not directly refer to T1 (as in the case of
a recursive definition), instead it refers (via the definition of
`gtypes-of`) to the set of all types, to which T1 happens to belong.
As it happens, the notion of *type* was invented/introduced by Bertrand
Russel (early 20th century) specifically in order to try and disallow
the kind of paradoxes (like Russel's paradox or the paradox of the
barber) that impredicativity makes possible.
OK, you can go back to your regularly scheduled ELisp hacking now,
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 26 Apr 2025 09:49:02 +0000
Resent-Message-ID: <handler.77725.B77725.174566088714761 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174566088714761
(code B ref 77725); Sat, 26 Apr 2025 09:49:02 +0000
Received: (at 77725) by debbugs.gnu.org; 26 Apr 2025 09:48:07 +0000
Received: from localhost ([127.0.0.1]:58274 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8c8j-0003px-Jd
for submit <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:48:06 -0400
Received: from smtp-25.smtpout.orange.fr ([80.12.242.25]:47525
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8c8e-0003pH-6T
for 77725 <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:48:02 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 8c8WueSn8Aix78c8ZuYvjs; Sat, 26 Apr 2025 11:47:58 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745660878;
bh=V4kIuvtBS3RAGzTxpUxKHiXWeSISP9w6TBYOz0dL6II=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=FlKt3lDzVot0DQpxiMR6AGrOIxkAB1tOQS/BX2PukzPTCJo/j48gRJxTfrWXgIL9k
F9qw3xidD5GWaCv6hueHC+VgiLidrFj/aLIoGwUfG+PAHBzgCEpijmdk7aLp9frYtC
TloKvQZ5YUEnnxT2t5Jt82GwaRAtmH2/VUqDGlp9vKcKuoMuwFw5J0hUNG20MQocM8
vHsNZAWrTqNFoLorsVgzpeDLfFJHpTQA8nwbDuNqOsucREocusO5FzDVYPIzkx7Fp/
Vt5lKmpeImzRikiRYpsUhkQCbHw0/dBO+W6GOa8FHwtdFpAfoOjmBftVMMtlVMD63e
fvhMQvqW8mX0Q==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sat, 26 Apr 2025 11:47:58 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------f9Pq14eM3v8f6UAXZV4u0vT5"
Message-ID: <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
Date: Sat, 26 Apr 2025 11:47:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------f9Pq14eM3v8f6UAXZV4u0vT5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2025-04-25 20:07, Stefan Monnier wrote:
>>>> (cl-deftype T1 ()
>>>> "Root type.
>>>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>>>> object type parents."
>>>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>>> Hmm... I can see that it could be handy if you don't know how to
>>> characterize type T1 other than as the "sum" of its subtypes.
>>> But this seems rather circular. Have you seen such things out in
>>> the wild?
>> I am using a such "abstract" type in one of my library for exactly
>> this: "characterize type T1 other than as the "sum" of its subtypes."
>
> [ FWIW, this definition makes your type-test quite costly since it will
> test more or less each and every type defined with `cl-deftype`.
> You'd be better served with a more targeted test which keeps track of
> the children of T1 so it can then do something like
>
> (cl-some (lambda (child) (cl-typep o child)) my-children)
>
> This way the performance is not affected by random other unrelated types.
>
> But, yes, that begs the question of how to keep track of the
> children, e.g. how to be told when a child needs to be added/removed
> to/from `my-children`. ]
Exactly, I fully agree, the question is "how to keep track of the children"?
I wonder if it would be possible to do something when the type is
(re)defined? For example, pass the type once defined to some kind of
"after-defined-hook" that could adjust the environment accordingly.
>>> More importantly, with your circularity-breaking approach, if `gtype-of`
>>> (aka `cl-types-of`) happens to look at T1 first, that check will
>>> immediately return nil, so `cl-types-of` may decide "Oh, I just
>>> discovered this is not a T1, so I can skip checking all the subtypes of
>>> T1". So, the cycle is broken, but the output is wrong.
>>
>> Look at T1 first should be possible only if T1 is alone, without any
> [...]
>
> Agreed.
>
>> Did I miss something?
>
> What you missed (because I didn't make it clear) is that I was talking
> about an incorrect behavior of your circularity-breaking approach, when
> coupled with *another* algorithm than the one you currently use to
> collect the set of types to return in `cl-types-of`.
Ah, OK, I better understand your point. Thanks!
>
>> This makes me think that errors that might occur when calling
>> `cl-typep' should be handled in `cl-types-of' to prevent an
>> incorrect definition from impacting method dispatching on types
>> correctly defined.
>> WDYT?
>
> Maybe. I'd tend to think that `cl-typep` should never error, so if it
> ever does (which would indicate a bug in some `cl-deftype`), we wouldn't
> want to hide that error.
Unfortunately, currently `cl-typep' can error, but currently the
impact is limited to the broken definition. Here is an example of
broken definition:
(cl-deftype bad-type ()
'(satisfies unknown-function))
But, when any type defined by 'cl-deftype' can also be a method type
argument, any broken type can also break dispatching of method for
other types. So, such errors need to be caught and reported by
`cl-types-of'. For now, I updated `cl-types-of' accordingly.
>
>>>> ;; T2 will never match, because `cl-types-of' enters in an endless recursion
>>>> (cl-typep (list 'T2) 'T1)
>>>> => nil
>>> This is both right and wrong: we could return t and that would be
>>> equally valid.
>>>
>>>> (cl-types-of (list 'T2))
>>>> => (cons list sequence t)
>>> And here (T2 T1 cons list sequence t) would also be equally valid.
>>
>> Sorry, you lost me here. As I understand it, a type whose definition
>> enter in an endless recursion is not valid, and should never match?
>
> It depends on whether you define your types inductively or co-inductively.
> IOW, do you define the type by starting with the "empty set" and then
> adding new elements to it until there's nothing more to add, or do you
> define it by starting with a "total set" that contains everything and
> then remove elements from it until you've removed everything that
> doesn't belong there.
>
> Another way to look at it: there's nothing in your definition of T2 that
> says that the list `(T2)` should *not* be an element of that type.
>
> For recursive values, in order to break circularity, it is common to
> check whether a value satisfies a constraint by adding "yes it does" as
> a temporary assumption while performing the check, so as to break the
> cycle when we get to a nested occurrence of that object.
> If we use the same approach here, the T2 test will say that `(T2)` is
> indeed of type T2.
>
I am afraid, I still don't see how I can implement this "common
approach" to break circularity.
When I consider that a type "match" before to check, it will still match
after a cycle is detected, if I understood correctly your explanation.
So, a circular type will always match for any objet? I certainly missed
something, sorry.
[...]
>>
>> The problem with this approach is that it is difficult to isolate and cleanup
>> the definitions needed for test-1 from those needed for test-2. Also the result
>> will depends on the order of the cl-deftype for test-1 and test-2, because these
>> definitions will be effective outside of test-1 and test-2.
>>
>> But maybe it's not so important after all. I'll try to reformulate the tests this way.
>
> In the worst case, you can duplicate the definitions (with different names).
Please find attached a new simpler and cleaner version of cl-types-test.el.
All tests pass for me :-)
Also attached my last version of cl-types.el. For now, I prefer to work on
separate files. Based on your previous proposal, it should not be difficult to
merge the code in existing libraries when/if we are satisfied of the
implementation ;-)
David
--------------f9Pq14eM3v8f6UAXZV4u0vT5
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types-tests.el"
Content-Disposition: attachment; filename="cl-types-tests.el"
Content-Transfer-Encoding: base64
Ozs7IFRlc3QgYGNsLXR5cGVkZWYnIC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQo7Owoo
cmVxdWlyZSAnZXJ0KQoocmVxdWlyZSAnY2wtdHlwZXMpCgooY2wtZGVmdHlwZTIgbXVsdGlw
bGVzLW9mICgmb3B0aW9uYWwgbSkKICAobGV0ICgobXVsdGlwbGVwIChpZiAoZXEgbSAnKikK
ICAgICAgICAgICAgICAgICAgICAgICAjJ2lnbm9yZQoJCSAgICAgKGxhbWJkYSAobikgKD0g
MCAoJSBuIG0pKSkpKSkKICAgIGAoYW5kIGludGVnZXIgKHNhdGlzZmllcyAsbXVsdGlwbGVw
KSkpKQogICAgIAooY2wtZGVmdHlwZTIgbXVsdGlwbGVzLW9mLTIgKCkKICAnKG11bHRpcGxl
cy1vZiAyKSkKICAgICAKKGNsLWRlZnR5cGUyIG11bHRpcGxlcy1vZi0zICgpCiAgJyhtdWx0
aXBsZXMtb2YgMykpCiAgICAgCihjbC1kZWZ0eXBlMiBtdWx0aXBsZXMtb2YtNCAoKQogIChk
ZWNsYXJlIChwYXJlbnRzIG11bHRpcGxlcy1vZi0yKSkKICAnKGFuZCBtdWx0aXBsZXMtb2Yt
MiAobXVsdGlwbGVzLW9mIDQpKSkKCihjbC1kZWZ0eXBlMiB1bnNpZ25lZC1ieXRlICgmb3B0
aW9uYWwgYml0cykKICAiVW5zaWduZWQgaW50ZWdlci4iCiAgYChpbnRlZ2VyIDAgLChpZiAo
ZXEgYml0cyAnKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQogICAgIAooY2wtZGVmdHlw
ZTIgdW5zaWduZWQtMTZiaXRzICgpCiAgIlVuc2lnbmVkIDE2LWJpdHMgaW50ZWdlci4iCiAg
KGRlY2xhcmUgKHBhcmVudHMgdW5zaWduZWQtYnl0ZSkpCiAgJyh1bnNpZ25lZC1ieXRlIDE2
KSkKICAgICAKKGNsLWRlZnR5cGUyIHVuc2lnbmVkLThiaXRzICgpCiAgIlVuc2lnbmVkIDgt
Yml0cyBpbnRlZ2VyLiIKICAoZGVjbGFyZSAocGFyZW50cyB1bnNpZ25lZC0xNmJpdHMpKQog
ICcodW5zaWduZWQtYnl0ZSA4KSkKICAgICAKKGNsLWRlZm1ldGhvZCBteS1mb28gKChfbiB1
bnNpZ25lZC1ieXRlKSkKICAoZm9ybWF0ICJ1bnNpZ25lZCIpKQogICAgIAooY2wtZGVmbWV0
aG9kIG15LWZvbyAoKF9uIHVuc2lnbmVkLTE2Yml0cykpCiAgKGZvcm1hdCAidW5zaWduZWQg
MTZiaXRzIC0gYWxzbyAlcyIKICAgICAgICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkpCiAg
ICAgCihjbC1kZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWduZWQtOGJpdHMpKQogIChmb3Jt
YXQgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyAlcyIKICAgICAgICAgIChjbC1jYWxsLW5leHQt
bWV0aG9kKSkpCgooZXJ0LWRlZnRlc3QgY2wtdHlwZXMtdGVzdCAoKQogICJUZXN0IHR5cGVz
IGRlZmluaXRpb24sIGNsLXR5cGVzLW9mIGFuZCBtZXRob2QgZGlzcGF0Y2hpbmcuIgoKICA7
OyBJbnZhbGlkIERBRyBlcnJvcgogIChzaG91bGQtZXJyb3IKICAgKGV2YWwKICAgICcoY2wt
ZGVmdHlwZTIgdW5zaWduZWQtMTZiaXRzICgpCiAgICAgICAiVW5zaWduZWQgMTYtYml0cyBp
bnRlZ2VyLiIKICAgICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLThiaXRzKSkKICAg
ICAgICcodW5zaWduZWQtYnl0ZSAxNikpCiAgICBsZXhpY2FsLWJpbmRpbmcKICAgICkpCgog
IDs7IFRlc3QgdGhhdCAoY2wtdHlwZXMtb2YgNCkgaXMgKG11bHRpcGxlcy1vZi00IG11bHRp
cGxlcy1vZi0yIC4uLikKICA7OyBUZXN0IHRoYXQgKGNsLXR5cGVzLW9mIDYpIGlzIChtdWx0
aXBsZXMtb2YtMyBtdWx0aXBsZXMtb2YtMiAuLi4pCiAgOzsgVGVzdCB0aGF0IChjbC10eXBl
cy1vZiAxMikgaXMgKG11bHRpcGxlcy1vZi00IG11bHRpcGxlcy1vZi0zIG11bHRpcGxlcy1v
Zi0yIC4uLikKICAobGV0ICgodHlwZXMgJyhtdWx0aXBsZXMtb2YtMiBtdWx0aXBsZXMtb2Yt
MyBtdWx0aXBsZXMtb2YtNCkpKQogICAgKHNob3VsZCAoZXF1YWwgJyhtdWx0aXBsZXMtb2Yt
MikKCQkgICAoc2VxLWludGVyc2VjdGlvbiAoY2wtdHlwZXMtb2YgMikgdHlwZXMpKSkKCiAg
ICAoc2hvdWxkIChlcXVhbCAnKG11bHRpcGxlcy1vZi00IG11bHRpcGxlcy1vZi0yKQoJCSAg
IChzZXEtaW50ZXJzZWN0aW9uIChjbC10eXBlcy1vZiA0KSB0eXBlcykpKQoKICAgIChzaG91
bGQgKGVxdWFsICcobXVsdGlwbGVzLW9mLTMgbXVsdGlwbGVzLW9mLTIpCgkJICAgKHNlcS1p
bnRlcnNlY3Rpb24gKGNsLXR5cGVzLW9mIDYpIHR5cGVzKSkpCgogICAgKHNob3VsZCAoZXF1
YWwgJyhtdWx0aXBsZXMtb2YtMyBtdWx0aXBsZXMtb2YtNCBtdWx0aXBsZXMtb2YtMikKCQkg
ICAoc2VxLWludGVyc2VjdGlvbiAoY2wtdHlwZXMtb2YgMTIpIHR5cGVzKSkpCiAgICAKICAg
IChzaG91bGQgKGVxdWFsICcoKQoJCSAgIChzZXEtaW50ZXJzZWN0aW9uIChjbC10eXBlcy1v
ZiA1KSB0eXBlcykpKQogICAgKQogIAogIDs7OyBNZXRob2QgZGlzcGF0Y2hpbmcuCiAgKHNo
b3VsZCAoZXF1YWwgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyB1bnNpZ25lZCAxNmJpdHMgLSBh
bHNvIHVuc2lnbmVkIgoJCSAobXktZm9vIDEwMCkpKQoKICAoc2hvdWxkIChlcXVhbCAidW5z
aWduZWQgMTZiaXRzIC0gYWxzbyB1bnNpZ25lZCIKCQkgKG15LWZvbyAyNTYpKSkKCiAgKHNo
b3VsZCAoZXF1YWwgInVuc2lnbmVkIgoJCSAobXktZm9vIG1vc3QtcG9zaXRpdmUtZml4bnVt
KSkpCiAgKQoKKHByb3ZpZGUgJ2NsLXR5cGVzLXRlc3RzKQoKOzs7IGNsLXR5cGVzLXRlc3Rz
LmVsIGVuZHMgaGVyZQo=
--------------f9Pq14eM3v8f6UAXZV4u0vT5
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBEYXRhIHR5cGVzIGRlZmluZWQg
YnkgYGNsLWRlZnR5cGUnIGFyZSBub3cgcmVjb2duaXplZCBhcyBhcmd1bWVudAo7OyB0eXBl
cyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbnMgbWV0aG9kcy4KCjs7IFdpbGwg
YmUgcmVtb3ZlZCB3aGVuIGluY2x1ZGVkIGluIGNsLWxpYi4KKHJlcXVpcmUgJ2NsLWxpYikK
KGV2YWwtd2hlbi1jb21waWxlIChyZXF1aXJlICdjbC1tYWNzKSkgIDtGb3IgY2wtLWZpbmQt
Y2xhc3MuCgo7OyBFeHRlbmQgYGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdo
aWNoIGFyZSBhbHNvIHZhbGlkCjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBn
ZW5lcmljIGZ1bmN0aW9uIG1ldGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3Mu
Z251Lm9yZy9jZ2kvYnVncmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4g
ZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBu
ZXcgZGF0YSB0eXBlcy4KOzsKOzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IHJldHVybnMgdGhl
IHR5cGVzIGFuIG9iamVjdCBiZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5p
bAogICJMaXN0IG9mIGRlZmluZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0
Y2hpbmcuIikKCjs7IEZJWE1FOiBUaGUgYGNsLWRlZnR5cGUtaGFuZGxlcicgcHJvcGVydHkg
c2hvdWxkIGFyZ3VhYmx5IGJlIHR1cm5lZAo7OyBpbnRvIGEgZmllbGQgb2YgdGhpcyBzdHJ1
Y3QgKGJ1dCBpdCBoYXMgcGVyZm9ybWFuY2UgYW5kCjs7IGNvbXBhdGliaWxpdHkgaW1wbGlj
YXRpb25zLCBzbyBsZXQncyBub3QgbWFrZSB0aGF0IGNoYW5nZSBmb3Igbm93KS4KKGNsLWRl
ZnN0cnVjdAogICAgKGNsLXR5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNsYXNzKQog
ICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAoOmNvbnN0
cnVjdG9yIGNsLS10eXBlLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAg
ICAgICAgICAgICAgICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50
LXR5cGVzCiAgICAgICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAg
ICAgICAgICAgICAgIChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJk
YSAodHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGNsLS1maW5kLWNs
YXNzIHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiVW5r
bm93biB0eXBlOiAlUyIgdHlwZSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJl
bnQtdHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBm
b3IgdHlwZXMgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScuIikKCihkZWZ1biBjbC0tdHlwZS1w
IChvYmplY3QpCiAgIlJldHVybiBub24tbmlsIGlmIE9CSkVDVCBpcyBhIHVzZWQgZGVmaW5l
ZCB0eXBlLgpUaGF0IGlzLCBhIHR5cGUgb2YgY2xhc3MgYGNsLXR5cGUtY2xhc3MnLiIKICAo
YW5kIChzeW1ib2xwIG9iamVjdCkgKGNsLXR5cGUtY2xhc3MtcCAoY2wtLWZpbmQtY2xhc3Mg
b2JqZWN0KSkpKQoKKGRlZm1hY3JvIGNsLS10eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdldCBw
YXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGlu
ZyBhIHR5cGUuIgogIGAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNzICxu
YW1lKSkpCgooZGVmdW4gY2wtLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGlsZHJl
biBvZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5n
IGEgdHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNs
LWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogIChsZXQgKGNoaWxk
cmVuKQogICAgKGRvbGlzdCAoZWx0IGNsLS10eXBlLWxpc3QpCiAgICAgIChvciAoZXEgbmFt
ZSBlbHQpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSAoY2wtLXR5cGUtcGFyZW50cyBlbHQp
KQogICAgICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkK
CihkZWZ1biBjbC0tdHlwZS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxpc3Qg
b2YgZGVmaW5lZCB0eXBlcy4iCiAgKG1hcGNhciAobGFtYmRhICh0eXBlKSAoY2wtLXR5cGUt
cGFyZW50cyB0eXBlKSkgY2wtLXR5cGUtbGlzdCkpCgo7OyBLZWVwIGl0IGZvciBub3csIGZv
ciB0ZXN0aW5nLgooZGVmdW4gY2wtLXR5cGUtdW5kZWZpbmUgKG5hbWUpCiAgIlJlbW92ZSB0
aGUgZGVmaW5pdGlvbnMgb2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4gdW5xdW90ZWQg
c3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClNpZ25hbCBhbiBlcnJvciBpZiBvdGhlciB0
eXBlcyBpbmhlcml0IGZyb20gTkFNRS4iCiAgKGRlY2xhcmUtZnVuY3Rpb24gY2wtcmVtcHJv
cCAiY2wtZXh0cmEiIChzeW1ib2wgcHJvcG5hbWUpKQogIChjbC1jaGVjay10eXBlIG5hbWUg
KHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAod2hlbi1sZXQqICgoY2hpbGRyZW4gKGFuZCAo
Y2wtLXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0tdHlw
ZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMi
IGNoaWxkcmVuKSkKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXBy
b3AgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRl
bHEgbmFtZSBjbC0tdHlwZS1saXN0KSkpCgooZGVmdW4gY2wtLXR5cGUtZGVmdHlwZSAobmFt
ZSBwYXJlbnRzICZvcHRpb25hbCBkb2NzdHJpbmcpCiAgIkdlbmVyYWxpemUgdHlwZSB3aXRo
IE5BTUUgZm9yIG1ldGhvZCBkaXNwYXRjaGluZy4KUEFSRU5UUyBpcyBhIGxpc3Qgb2YgdHlw
ZXMgTkFNRSBpcyBhIHN1YnR5cGUgb2YsIG9yIG5pbC4KRE9DU1RSSU5HIGlzIGFuIG9wdGlv
bmFsIGRvY3VtZW50YXRpb24gc3RyaW5nLiIKICAobGV0ICgob2xkdGxpc3QgKGNvcHktc2Vx
dWVuY2UgY2wtLXR5cGUtbGlzdCkpCiAgICAgICAgKG9sZHBsaXN0IChjb3B5LXNlcXVlbmNl
IChzeW1ib2wtcGxpc3QgbmFtZSkpKSkKICAgIChjb25kaXRpb24tY2FzZSBlcnIKICAgICAg
ICAobGV0KiAoKGNsYXNzIChjbC0tZmluZC1jbGFzcyBuYW1lKSkKICAgICAgICAgICAgICAg
KHJlY29yZGVkIChtZW1xIG5hbWUgY2wtLXR5cGUtbGlzdCkpKQogICAgICAgICAgKGlmIChu
dWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVsbCByZWNvcmRlZCkKICAgICAgICAg
ICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVkLCBidXQgZG9lc24ndCBleGlzdCIp
KQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9yICJUeXBlIGV4aXN0cywgYnV0IG5v
dCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3IgKGNsLXR5cGUtY2xhc3MtcCBjbGFz
cykKICAgICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBhbm90aGVyIGNsYXNzOiAlUyIg
KHR5cGUtb2YgY2xhc3MpKSkpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSBwYXJlbnRzKQog
ICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykpCiAg
ICAgICAgICA7OyBTZXR1cCBhIHR5cGUgZGVzY3JpcHRvciBmb3IgTkFNRS4KICAgICAgICAg
IChzZXRmIChjbC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAgICAgKGNsLS10eXBl
LWNsYXNzLW1ha2UgbmFtZSBkb2NzdHJpbmcgcGFyZW50cykpCiAgICAgICAgICA7OyBSZWNv
cmQgbmV3IHR5cGUgbm93IHRvIGluY2x1ZGUgaXRzIGRlcGVuZGVuY3kgaW4gdGhlIERBRy4K
ICAgICAgICAgIChvciByZWNvcmRlZCAocHVzaCBuYW1lIGNsLS10eXBlLWxpc3QpKQogICAg
ICAgICAgOzsgYGNsLXR5cGVzLW9mJyBpdGVyYXRlcyB0aHJvdWdoIGFsbCBrbm93biB0eXBl
cyB0byBjb2xsZWN0CiAgICAgICAgICA7OyBhbGwgdGhvc2UgYW4gb2JqZWN0IGJlbG9uZ3Mg
dG8sIHNvcnRlZCBmcm9tIHRoZSBtb3N0CiAgICAgICAgICA7OyBzcGVjaWZpYyB0eXBlIHRv
IHRoZSBtb3JlIGdlbmVyYWwgdHlwZS4gIFNvLCBrZWVwIHRoZQogICAgICAgICAgOzsgZ2xv
YmFsIGxpc3QgaW4gdGhpcyBvcmRlci4KICAgICAgICAgIChzZXRxIGNsLS10eXBlLWxpc3QK
ICAgICAgICAgICAgICAgIChtZXJnZS1vcmRlcmVkLWxpc3RzCiAgICAgICAgICAgICAgICAg
KGNsLS10eXBlLWRhZykKICAgICAgICAgICAgICAgICAobGFtYmRhIChfKSAoZXJyb3IgIklu
dmFsaWQgZGVwZW5kZW5jeSBncmFwaCIpKSkpKQogICAgICAoZXJyb3IKICAgICAgIDs7IE9u
IGVycm9yIHJlc3RvcmUgcHJldmlvdXMgZGF0YS4KICAgICAgIChzZXRxIGNsLS10eXBlLWxp
c3Qgb2xkdGxpc3QpCiAgICAgICAoc2V0ZiAoc3ltYm9sLXBsaXN0IG5hbWUpIG9sZHBsaXN0
KQogICAgICAgKGVycm9yIChmb3JtYXQgIkRlZmluZSAlUyBmYWlsZWQ6ICVzIgogICAgICAg
ICAgICAgICAgICAgICAgbmFtZSAoZXJyb3ItbWVzc2FnZS1zdHJpbmcgZXJyKSkpKSkpKQoK
Ozs7IyMjYXV0b2xvYWQKKGRlZm1hY3JvIGNsLWRlZnR5cGUyIChuYW1lIGFyZ2xpc3QgJnJl
c3QgYm9keSkKICAiRGVmaW5lIE5BTUUgYXMgYSBuZXcgZGF0YSB0eXBlLgpUaGUgdHlwZSBO
QU1FIGNhbiB0aGVuIGJlIHVzZWQgaW4gYGNsLXR5cGVjYXNlJywgYGNsLWNoZWNrLXR5cGUn
LApldGMuLCBhbmQgYXMgYXJndW1lbnQgdHlwZSBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBm
dW5jdGlvbiBtZXRob2RzLgoKQVJHTElTVCBpcyBhIENvbW1vbiBMaXNwIGFyZ3VtZW50IGxp
c3Qgb2YgdGhlIHNvcnQgYWNjZXB0ZWQgYnkKYGNsLWRlZm1hY3JvJy4gIEJPRFkgZm9ybXMg
YXJlIGV2YWx1YXRlZCBhbmQgc2hvdWxkIHJldHVybiBhIHR5cGUKc3BlY2lmaWVyIHRoYXQg
aXMgZXF1aXZhbGVudCB0byB0aGUgdHlwZSAoc2VlIHRoZSBJbmZvIG5vZGUgYChjbCkgVHlw
ZQpQcmVkaWNhdGVzJyBpbiB0aGUgR05VIEVtYWNzIENvbW1vbiBMaXNwIEVtdWxhdGlvbiBt
YW51YWwpLgoKSWYgdGhlcmUgaXMgYSBgZGVjbGFyZScgZm9ybSBpbiBCT0RZLCB0aGUgc3Bl
YyAocGFyZW50cyBQQVJFTlRTKSBpcwpyZWNvZ25pemVkIHRvIHNwZWNpZnkgYSBsaXN0IG9m
IHR5cGVzIE5BTUUgaXMgYSBzdWJ0eXBlIG9mLiAgRm9yCmluc3RhbmNlOgoKICAoY2wtZGVm
dHlwZTIgdW5zaWduZWQtYnl0ZSAoJm9wdGlvbmFsIGJpdHMpCiAgICBcIlVuc2lnbmVkIGlu
dGVnZXIuXCIKICAgIChsaXN0IFxcPSdpbnRlZ2VyIDAgKGlmIChlcSBiaXRzIFxcPScqKSBi
aXRzICgxLSAoYXNoIDEgYml0cykpKSkpCgogIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC04Yml0
cyAoKQogICAgXCJVbnNpZ25lZCA4LWJpdHMgaW50ZWdlci5cIgogICAgKGRlY2xhcmUgKHBh
cmVudHMgdW5zaWduZWQtYnl0ZSkpCiAgICBcXD0nKHVuc2lnbmVkLWJ5dGUgOCkpCgpUaGUg
bGlzdCBvZiBQQVJFTlRTIHR5cGVzIGRldGVybWluZXMgdGhlIG9yZGVyIG9mIG1ldGhvZHMg
aW52b2NhdGlvbiwKYW5kIG1pc3NpbmcgUEFSRU5UUyBtYXkgY2F1c2UgaW5jb3JyZWN0IG9y
ZGVyaW5nIG9mIG1ldGhvZHMsIHdoaWxlCmV4dHJhbmVvdXMgUEFSRU5UUyBtYXkgY2F1c2Ug
dXNlIG9mIGV4dHJhbmVvdXMgbWV0aG9kcy4KCklmIFBBUkVOVFMgaXMgbm9uLW5pbCwgQVJH
TElTVCBtdXN0IGJlIG5pbC4iCiAgKGRlY2xhcmUgKGRlYnVnIGNsLWRlZm1hY3JvKSAoZG9j
LXN0cmluZyAzKSAoaW5kZW50IDIpKQogIChwY2FzZS1sZXQqCiAgICAgICgoYCgsZGVjbHMg
LiAsZm9ybXMpIChtYWNyb2V4cC1wYXJzZS1ib2R5IGJvZHkpKQogICAgICAgKGRvY3N0cmlu
ZyAoaWYgKHN0cmluZ3AgKGNhciBkZWNscykpCiAgICAgICAgICAgICAgICAgICAgICAoY2Fy
IGRlY2xzKQogICAgICAgICAgICAgICAgICAgIChjYWRyIChhc3NxIDpkb2N1bWVudGF0aW9u
IGRlY2xzKSkpKQogICAgICAgKHBhcmVudHMgKGNkciAoYXNzcSAncGFyZW50cyAoY2RyIChh
c3NxICdkZWNsYXJlIGRlY2xzKSkpKSkpCiAgICAoYW5kIHBhcmVudHMgYXJnbGlzdAogICAg
ICAgICAoZXJyb3IgIlBhcmVudHMgc3BlY2lmaWVkLCBidXQgYXJnbGlzdCBub3QgZW1wdHki
KSkKICAgIChpZiBkb2NzdHJpbmcgKHNldHEgZm9ybXMgKGNvbnMgZG9jc3RyaW5nIGZvcm1z
KSkpCiAgICBgKGV2YWwtYW5kLWNvbXBpbGUgOztjbC1ldmFsLXdoZW4gKGNvbXBpbGUgbG9h
ZCBldmFsKQogICAgICAgKGNsLS10eXBlLWRlZnR5cGUgJyxuYW1lICcscGFyZW50cyAsZG9j
c3RyaW5nKQogICAgICAgKGRlZmluZS1zeW1ib2wtcHJvcCAnLG5hbWUgJ2NsLWRlZnR5cGUt
aGFuZGxlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAoY2wtZnVuY3Rpb24KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKCZjbC1kZWZzICgnKikgLEBhcmdsaXN0
KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAsQGZvcm1zKSkpKSkpCgo7OyBJbnRl
cm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3MgcmVjdXJzaW9uIGluICdjbC10eXBl
LW9mJy4KKGRlZnZhciBjbC0tdHlwZS1vYmplY3QgKG1ha2Utc3ltYm9sICJ2b2lkIikpCjs7
IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwnLgooZGVmdmFyIGNsLS10eXBlLXVu
aXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkKICAiUmVjb3JkIGFuIHVuaXF1
ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCjs7IEZJWE1FOiBgY2wtdHlwZXMtb2YnIENQVSBj
b3N0IGlzIHByb3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9mIHR5cGVzCjs7IGRlZmluZWQg
d2l0aCBgY2wtZGVmdHlwZScsIHNvIHRoZSBtb3JlIHBvcHVsYXIgaXQgZ2V0cywgdGhlIHNs
b3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5kIG9mIGNvdXJzZSwgdGhlIGNvc3Qgb2YgZWFjaCB0
eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRlZCwgc28gYSBzaW5nbGUgImV4cGVuc2l2ZSIgdHlw
ZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRvd24KOzsgZnVydGhlci4KOzsKOzsgVGhlIHVzdWFs
IGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxhbWJkYSAoYXJnICZyZXN0IGFyZ3MpCjs7ICAgICAo
bGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlwZW9mIGFyZykgcHJlY29tcHV0ZWQtbWV0aG9kcy10
YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7OyAgICAgICAgICAgKGFwcGx5IGYgYXJnIGFyZ3Mp
Cjs7ICAgICAgICAgOzsgU2xvdyBjYXNlIHdoZW4gZW5jb3VudGVyaW5nIGEgbmV3IHR5cGUK
OzsgICAgICAgICAuLi4pKSkKOzsKOzsgd2hlcmUgb2Z0ZW4gdGhlIG1vc3QgZXhwZW5zaXZl
IHBhcnQgaXMgYCZyZXN0JyAod2hpY2ggaGFzIHRvCjs7IGFsbG9jYXRlIGEgbGlzdCBmb3Ig
dGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50cyksCjs7Cjs7IFNvIHdlJ3JlIHRhbGtpbmcgYWJv
dXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJlc3QgKyBjbC10eXBlLW9mICsgZ2V0aGFzaCArIGlm
ICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1bmN0aW9uIHRoYXQgbG9vcHMgb3ZlciBOIHR5cGVz
LCBjYWxsaW5nIGBjbC10eXBlcCcgb24gZWFjaAo7OyBvbmUgb2YgdGhlbSAoYGNsLXR5cGVw
JyBpdHNlbGYgYmVpbmcgYSByZWN1cnNpdmUgZnVuY3Rpb24gdGhhdAo7OyBiYXNpY2FsbHkg
aW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5ndWFnZSkuICBUaGlzIGlzIGdvaW5nIHRvIHNsb3cK
OzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNpZ25pZmljYW50bHkgZm9yIHRob3NlIGdlbmVyaWMg
ZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBhIG1ldGhvZCB0aGF0IGRpc3BhdGNoZXMgb24gYSB1
c2VyIGRlZmluZWQgdHlwZSwgY29tcGFyZWQgdG8KOzsgdGhvc2UgdGhhdCBkb24ndC4KOzsK
OzsgQSBwb3NzaWJsZSBmdXJ0aGVyIGltcHJvdmVtZW50Ogo7Owo7OyAtIGJhc2VkIG9uIHRo
ZSBQQVJFTlRTIGRlY2xhcmF0aW9uLCBjcmVhdGUgYSBtYXAgZnJvbSBidWlsdGluLXR5cGUK
OzsgICB0byB0aGUgc2V0IG9mIGNsLXR5cGVzIHRoYXQgaGF2ZSB0aGF0IGJ1aWx0aW4tdHlw
ZSBhbW9uZyB0aGVpcgo7OyAgIHBhcmVudHMuICBUaGF0IHByZXN1bWVzIHNvbWUgUEFSRU5U
UyBpbmNsdWRlIHNvbWUgYnVpbHRpbi10eXBlcywKOzsgICBvYnZpb3VzbHkgb3RoZXJ3aXNl
IHRoZSBtYXAgd2lsbCBiZSB0cml2aWFsIHdpdGggYWxsIGNsLXR5cGVzCjs7ICAgYXNzb2Np
YXRlZCB3aXRoIHRoZSBgdCcgImR1bW15IHBhcmVudCIuICBbIFdlIGNvdWxkIGV2ZW4gZ28g
Y3JhenkKOzsgICBhbmQgdHJ5IGFuZCBndWVzcyBQQVJFTlRTIHdoZW4gbm90IHByb3ZpZGVk
LCBieSBhbmFseXppbmcgdGhlCjs7ICAgdHlwZSdzIGRlZmluaXRpb24uIF0KOzsKOzsgLSBp
biBgY2wtdHlwZXMtb2YnIHN0YXJ0IGJ5IGNhbGxpbmcgYGNsLXR5cGUtb2YnLCB0aGVuIHVz
ZSB0aGUgbWFwCjs7ICAgdG8gZmluZCB3aGljaCBjbC10eXBlcyBtYXkgbmVlZCB0byBiZSBj
aGVja2VkLgo7OwooZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSB0
eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5cGVz
IE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMgdHlw
ZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJzaXZlIGNhbGwgb24g
dGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAgOzsgb2NjdXIgd2hl
biBhIHBhcmVudCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIgYW4gb2JqZWN0J3MgdHlwZSBp
cwogIDs7IHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJlbi4KICAodW5sZXNzIChlcSBvYmpl
Y3QgY2wtLXR5cGUtb2JqZWN0KQogICAgKGxldCAoKGNsLS10eXBlLW9iamVjdCBvYmplY3Qp
CiAgICAgICAgICAoZm91bmQgKGxpc3QgKGNsLS10eXBlLXBhcmVudHMgKGNsLXR5cGUtb2Yg
b2JqZWN0KSkpKSkKICAgICAgOzsgQnVpbGQgYSBEQUcgb2YgYWxsIHR5cGVzIE9CSkVDVCBi
ZWxvbmdzIHRvLgogICAgICAoZG9saXN0ICh0eXBlIGNsLS10eXBlLWxpc3QpCiAgICAgICAg
OzsgU2tpcCB0eXBlcyB0aGF0IHByb2R1Y2UgYW4gZXJyb3IuCiAgICAgICAgKGNvbmRpdGlv
bi1jYXNlIGVycgogICAgICAgICAgICAoYW5kCiAgICAgICAgICAgICA7OyBTa2lwIHR5cGUg
bm90IGRlZmluZWQgYnkgYGNsLWRlZnR5cGUnLgogICAgICAgICAgICAgKGNsLXR5cGUtY2xh
c3MtcCAoY2wtLWZpbmQtY2xhc3MgdHlwZSkpCiAgICAgICAgICAgICA7OyBJZiBCQVIgaXMg
ZGVjbGFyZWQgYXMgYSBwYXJlbnQgb2YgRk9PIGFuZAogICAgICAgICAgICAgOzsgYGNsLXR5
cGVzLW9mJyBoYXMgYWxyZWFkeSBkZWNpZGVkIHRoYXQgdGhlIHZhbHVlIGlzIG9mCiAgICAg
ICAgICAgICA7OyB0eXBlIEZPTywgdGhlbiB3ZSBhbHJlYWR5IGtub3cgQkFSIHdpbGwgYmUg
aW4gdGhlCiAgICAgICAgICAgICA7OyBvdXRwdXQgYW55d2F5IGFuZCB0aGVyZSdzIG5vIHBv
aW50IHRlc3RpbmcgQkFSLiAgU28sCiAgICAgICAgICAgICA7OyBza2lwIHR5cGUgYWxyZWFk
eSBzZWxlY3RlZCBhcyBwYXJlbnQgb2YgYW5vdGhlciB0eXBlLAogICAgICAgICAgICAgOzsg
YXNzdW1pbmcgdGhhdCwgbW9zdCBvZiB0aGUgdGltZSwgYGFzc3EnIHdpbGwgYmUgZmFzdGVy
CiAgICAgICAgICAgICA7OyB0aGFuIGBjbC10eXBlcCcuCiAgICAgICAgICAgICAobnVsbCAo
YXNzcSB0eXBlIGZvdW5kKSkKICAgICAgICAgICAgIDs7IElmIE9CSkVDVCBpcyBvZiB0eXBl
LCBhZGQgdHlwZSBhbmQgcGFyZW50cyB0byB0aGUgREFHLgogICAgICAgICAgICAgKGNsLXR5
cGVwIG9iamVjdCB0eXBlKQogICAgICAgICAgICAgOzsgKGRvbGlzdCAocCAoY2wtLXR5cGUt
cGFyZW50cyB0eXBlKSkKICAgICAgICAgICAgIDs7ICAgKHB1c2ggKGNsLS10eXBlLXBhcmVu
dHMgcCkgZm91bmQpKQogICAgICAgICAgICAgOzsgRXF1aXZhbGVudCB0byB0aGUgYGRvbGlz
dCcgYWJvdmUsIGJ1dCBmYXN0ZXI6IGF2b2lkIHRvCiAgICAgICAgICAgICA7OyByZWNvbXB1
dGUgc2V2ZXJhbCBsaXN0cyBvZiBwYXJlbnRzIHdlIGFscmVhZHkga25vdy4KICAgICAgICAg
ICAgIChsZXQgKChwbCAoY2wtLXR5cGUtcGFyZW50cyB0eXBlKSkpCiAgICAgICAgICAgICAg
ICh3aGlsZSBwbAogICAgICAgICAgICAgICAgIChwdXNoIHBsIGZvdW5kKQogICAgICAgICAg
ICAgICAgIChzZXRxIHBsIChjZHIgcGwpKSkpKQogICAgICAgICAgKGVycm9yCiAgICAgICAg
ICAgKG1lc3NhZ2UgImNsLXR5cGVzLW9mLCAlcyIgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVy
cikpKSkpCiAgICAgIDs7IENvbXB1dGUgYW4gb3JkZXJlZCBsaXN0IG9mIHR5cGVzIGZyb20g
dGhlIGNvbGxlY3RlZCBEQUcuCiAgICAgIChzZXRxIGZvdW5kIChtZXJnZS1vcmRlcmVkLWxp
c3RzIGZvdW5kKSkKICAgICAgOzsgUmV0dXJuIGFuIHVuaXF1ZSB2YWx1ZSBvZiB0aGlzIGxp
c3Qgb2YgdHlwZXMsIHdoaWNoIGlzIGFsc28KICAgICAgOzsgdGhlIGxpc3Qgb2Ygc3BlY2lm
aWVycyBmb3IgdGhpcyB0eXBlLgogICAgICAod2l0aC1tZW1vaXphdGlvbiAoZ2V0aGFzaCBm
b3VuZCBjbC0tdHlwZS11bmlxdWUpCiAgICAgICAgZm91bmQpKSkpCgo7OzsgTWV0aG9kIGRp
c3BhdGNoaW5nCjs7CihjbC1nZW5lcmljLWRlZmluZS1nZW5lcmFsaXplciBjbC0tdHlwZS1n
ZW5lcmFsaXplcgogIDIwIDs7ICJ0eXBlb2YiIDwgImNsLXR5cGVzLW9mIiA8ICJoZWFkIiBw
cmlvcml0eQogIChsYW1iZGEgKG9iaiAmcmVzdCBfKSBgKGNsLXR5cGVzLW9mICxvYmopKQog
IChsYW1iZGEgKHRhZyAmcmVzdCBfKSAoaWYgKGNvbnNwIHRhZykgdGFnKSkpCgooY2wtZGVm
bWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6ZXJzIDpleHRyYSAiY2wtdHlwZXMtb2YiICh0
eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBvbiB0eXBlcy4iCiAgKGlmIChjbC0tdHlw
ZS1wIHR5cGUpCiAgICAgIChsaXN0IGNsLS10eXBlLWdlbmVyYWxpemVyKQogICAgKGNsLWNh
bGwtbmV4dC1tZXRob2QpKSkKCihwcm92aWRlICdjbC10eXBlcykKCjs7OyBjbC10eXBlcy5l
bCBlbmRzIGhlcmUK
--------------f9Pq14eM3v8f6UAXZV4u0vT5--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 26 Apr 2025 09:51:02 +0000
Resent-Message-ID: <handler.77725.B77725.174566104115430 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174566104115430
(code B ref 77725); Sat, 26 Apr 2025 09:51:02 +0000
Received: (at 77725) by debbugs.gnu.org; 26 Apr 2025 09:50:41 +0000
Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8cBF-00040o-76
for submit <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:50:41 -0400
Received: from smtp-22.smtpout.orange.fr ([80.12.242.22]:41359
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8cBD-00040d-7q
for 77725 <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:50:39 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 8cB6u4lV520Vo8cB9u443m; Sat, 26 Apr 2025 11:50:37 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745661037;
bh=NfItWs6JcX20stFu62H/Bljazp2txX4pRZ5p1gFaFKA=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=i0EvV0yxTf7Wo/4RwntQQt2BbAt5bzmCyOWlv0mT82ps2NQ0yt1YPvv7f+udOvIwH
Isc+YSmrrQhIAo+vT0unV415mHTnQAoNhfOx6joUFGrmaMiSvgvc8kl6cLzUu5o2gZ
3taPbSINyiL3moucO7/2+sBdsnOjjadLBt13qkmpUJXvhoLhrraic3Yc8YF+olDH5V
Mtpgpnt+so513Gxgk0KghVPlzkpe9Kr9Ww1i3B9akQrk/+aOPPjebOUtZW9w0nh3qd
v71i/4iILIuo8v/bYZeY9GGW+Tfb+yXAvXFY4KutuF9vq62E3A11KYTubbQu/ilyHh
SFUpB6Uzt88Cg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sat, 26 Apr 2025 11:50:37 +0200
X-ME-IP: 90.112.40.65
Message-ID: <daf6e3c9-a6f9-4ced-b859-8774f467f176@HIDDEN>
Date: Sat, 26 Apr 2025 11:50:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<jwv7c38avsu.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv7c38avsu.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-25 21:37, Stefan Monnier wrote:
> [ Just tooting my horn, nothing to see. ]
>
>>> Here is a test case with a recursion:
>>>
>>> (cl-deftype T1 ()
>>> "Root type.
>>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>>> object type parents."
>>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>>
>> Hmm... I can see that it could be handy if you don't know how to
>> characterize type T1 other than as the "sum" of its subtypes.
>> But this seems rather circular. Have you seen such things out in
>> the wild?
>
> BTW, this form of circularity is called an *impredicative* definition:
> the above definition does not directly refer to T1 (as in the case of
> a recursive definition), instead it refers (via the definition of
> `gtypes-of`) to the set of all types, to which T1 happens to belong.
>
> As it happens, the notion of *type* was invented/introduced by Bertrand
> Russel (early 20th century) specifically in order to try and disallow
> the kind of paradoxes (like Russel's paradox or the paradox of the
> barber) that impredicativity makes possible.
>
> OK, you can go back to your regularly scheduled ELisp hacking now,
Thank you! I always appreciate enriching my knowledge :-)
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 27 Apr 2025 05:56:01 +0000
Resent-Message-ID: <handler.77725.B77725.174573330926372 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174573330926372
(code B ref 77725); Sun, 27 Apr 2025 05:56:01 +0000
Received: (at 77725) by debbugs.gnu.org; 27 Apr 2025 05:55:09 +0000
Received: from localhost ([127.0.0.1]:38129 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8uyq-0006rB-Lc
for submit <at> debbugs.gnu.org; Sun, 27 Apr 2025 01:55:09 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39902)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u8uyn-0006mE-0o
for 77725 <at> debbugs.gnu.org; Sun, 27 Apr 2025 01:55:05 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A9644440910;
Sun, 27 Apr 2025 01:54:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745733296;
bh=3Ju6BTYEXlSeSjQpIKcGXfSiH5rS51Azo1bfSatsTBs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=jdXcecUaNSwkyYshBYVk4wIv4TrRHoganBi7eAd5Ty37mJCYrp+i5YPAJv+2eXIqe
Mt0thvssUP+gloMlob30FVpyHZct258NZK6PoOkQYH6Opdpguo2aDoaEXFnnzBs+cG
VH6x5iCyW6Cqpc5BrIaMA1qmPBIvO+Otd+kMEQ3ieAsBakfko2lHE/gNJ26HnhnmtD
y9ofk+UREi70p0HD1GwxJ907lhZ4pwnXl4UlVQDd+6o8GQ84AxaCfKyZ98tUXfMPQD
ycB7ozzrO/XN3QpF3htAMKClSzzcoeShwIT89XdBRkkBG0qlGA8RAQL8hhU69UO+LX
tQN9Yozkw+RUA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1E57544046A;
Sun, 27 Apr 2025 01:54:56 -0400 (EDT)
Received: from alfajor (104-195-232-56.cpe.teksavvy.com [104.195.232.56])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DDB3F1201F3;
Sun, 27 Apr 2025 01:54:55 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
Message-ID: <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
Date: Sun, 27 Apr 2025 01:54:55 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.018 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Exactly, I fully agree, the question is "how to keep track of the
> children"?
You could approximate it with `after-load-functions`. Or, with the
proposed patch, you could use an advice on `cl--type-deftype`. Once you
do that, you won't need to break circularity in `cl-types-of`.
> I wonder if it would be possible to do something when the type is
> (re)defined? For example, pass the type once defined to some kind of
> "after-defined-hook" that could adjust the environment accordingly.
Maybe more generally we could/should provide "fast" (i.e. cached)
versions of `cl--class-allparents` and `cl--class-children`.
[ And remove those `--`. ]
>>> This makes me think that errors that might occur when calling
>>> `cl-typep' should be handled in `cl-types-of' to prevent an
>>> incorrect definition from impacting method dispatching on types
>>> correctly defined.
>>> WDYT?
>> Maybe. I'd tend to think that `cl-typep` should never error, so if
>> it ever does (which would indicate a bug in some `cl-deftype`), we
>> wouldn't want to hide that error.
> Unfortunately, currently `cl-typep' can error, but currently the
> impact is limited to the broken definition. Here is an example of
> broken definition:
>
> (cl-deftype bad-type ()
> '(satisfies unknown-function))
But this is bug in the definition of the type.
> But, when any type defined by 'cl-deftype' can also be a method type
> argument, any broken type can also break dispatching of method for
> other types. So, such errors need to be caught and reported by
> `cl-types-of'. For now, I updated `cl-types-of' accordingly.
You could also take the position that we shouldn't catch those errors
and instead put pressure to fix those broken `cl-deftype` definitions.
> I am afraid, I still don't see how I can implement this "common
> approach" to break circularity.
I think it would look something like:
(defvar cl--type-pending nil)
(defun cl--typep (o type)
;; Like `cl-typep` but with recursion-check.
(let ((entry (cons o type)))
;; Note: `member` is not quite right.
(if (member entry cl--type-pending)
;; We're called recursively while in the process of testing
;; if `o` is of type `type`, so presume it's true for now,
;; rather than inf-loop.
t
(let ((cl--type-pending (cons cl--type-pending)))
(cl-typep o type)))))
(defun cl-types-of (o)
(let ((types ()))
(dolist (type ...alltypes...)
(when (cl--typep o type)
(push type types))))))
...types...))
> When I consider that a type "match" before to check, it will still
> match after a cycle is detected, if I understood correctly your
> explanation. So, a circular type will always match for any objet?
If the type is "trivially circular", yes. Otherwise, not necessarily.
E.g.
(cl-deftype is-cons (t1 t2)
`(and cons (satisfies
,(lambda (x)
(and (cl--typep (car x) t1) (cl--typep (car x) t2))))))
(cl-deftype list-of-int ()
`(is-cons integer (or null list-of-int)))
and then
(let ((x (list 1 2 3 4 5)))
(setcdr (last x) x)
(cl--typep x 'list-of-int))
would terminate and return t but
(let ((x (list "1" "2" "3" "4" "5")))
(setcdr (last x) x)
(cl--typep x 'list-of-int))
would return nil.
> Please find attached a new simpler and cleaner version of
> cl-types-test.el. All tests pass for me :-)
Looks good, thanks.
> Also attached my last version of cl-types.el. For now, I prefer to
> work on separate files. Based on your previous proposal, it should
> not be difficult to merge the code in existing libraries when/if we
> are satisfied of the implementation ;-)
It would be good to check that the split I proposed works correctly, tho.
The main issues are likely to be around whether things are autoloaded
when they to.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 27 Apr 2025 13:00:02 +0000
Resent-Message-ID: <handler.77725.B77725.174575877611949 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174575877611949
(code B ref 77725); Sun, 27 Apr 2025 13:00:02 +0000
Received: (at 77725) by debbugs.gnu.org; 27 Apr 2025 12:59:36 +0000
Received: from localhost ([127.0.0.1]:40307 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u91bb-00036e-Rk
for submit <at> debbugs.gnu.org; Sun, 27 Apr 2025 08:59:36 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7253)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u91bY-00035R-4l
for 77725 <at> debbugs.gnu.org; Sun, 27 Apr 2025 08:59:33 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 336348086D;
Sun, 27 Apr 2025 08:59:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745758765;
bh=U5gT6UNmPJUexJkGPJ7ImJA2vnhpWp8NQlZK8VIr5BY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=FJHFS8JOkMjXllJzUogV9vA0ee5+KJ5eWVyZV7tEy9839Gd2mnknXI4JQ7l5KfChp
dX5/JPLZcZYqhbPHIltbiQ441+/fgwcaGXflCjxb7w6nXzeXdk4UGt+mIih81zeG5Q
9DauGPbtrmOAlJC4YdKGwRu/nHbk0EjYn/CQp5f/BTcu9pwdWaCZsB4PDdeNMuaB4Y
GWzL5SqYSekMVNwLZ1+Js/B7YkAx+EIw1wNPgovZ/IJeL4e8M0NEJwlH5rgnlCH59P
ISlvz1Ei5lCjlbEEQD/mx1wB0S3IZfw1++PnWwJDVeDMpSuDW+zbARPD+4P1Tlaozp
SRKUhsRWLLeaQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 548618089D;
Sun, 27 Apr 2025 08:59:25 -0400 (EDT)
Received: from alfajor (104-195-232-56.cpe.teksavvy.com [104.195.232.56])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 21EF212049E;
Sun, 27 Apr 2025 08:59:25 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
Date: Sun, 27 Apr 2025 08:59:24 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.064 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Exactly, I fully agree, the question is "how to keep track of the
>> children"?
>
> You could approximate it with `after-load-functions`. Or, with the
> proposed patch, you could use an advice on `cl--type-deftype`. Once you
> do that, you won't need to break circularity in `cl-types-of`.
I think what I was trying to say all along is:
the circularity you're trying to break doesn't come from `cl-deftype` or
`cl-types-of` but from your impredicative definition of `T1`.
So it'd be best to fix it there:
(cl-deftype T1 ()
`(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))
=>
(defvar my-pending-T1-check (make-symbol "void"))
(cl-deftype T1 ()
`(satisfies
,(lambda (o)
(and (not (eq o my-pending-T1-check))
(let ((my-pending-T1-check o))
(memq 'T1 (cl-types-of o)))))))
- Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 27 Apr 2025 15:32:02 +0000
Resent-Message-ID: <handler.77725.B77725.1745767911499 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.1745767911499
(code B ref 77725); Sun, 27 Apr 2025 15:32:02 +0000
Received: (at 77725) by debbugs.gnu.org; 27 Apr 2025 15:31:51 +0000
Received: from localhost ([127.0.0.1]:43669 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u93yw-00007z-Pj
for submit <at> debbugs.gnu.org; Sun, 27 Apr 2025 11:31:51 -0400
Received: from smtp-17.smtpout.orange.fr ([80.12.242.17]:55195
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u93yt-00007l-Rv
for 77725 <at> debbugs.gnu.org; Sun, 27 Apr 2025 11:31:49 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 93yluiUwfXKsE93ypugVdF; Sun, 27 Apr 2025 17:31:46 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745767906;
bh=fVIvenwD5GLJE3nEW3Nlaj9Wz0vnrfXXz7iGUXYaq4c=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=Ium3aheJJWChKlAGAPCAGlPDqGV7JbawfGs9M1JLOVTZ+oBqHiRFueRyJUQa5wovV
V3Dis3vBQKK2ZWy62Xo6HSihiQxtqMwI3u58h2i/sAQw+oE0jyQhM0lev2P96lKHRW
8gZnTQylGccdKy6R6NHej+BJLpIirg1vRiuzdgv6QkOJhSrEl6KI/0ERbzlWfygWWK
wufvpBSLsMXWJDE7ZuNAJIbHGriCkNqJ8ks3D/3ugWCMUhJB1zN+QVdzuoeymL4RSY
+w6a0CUEVZe69hgwP+/j+cKiJ+PG6jhYuBLr2VYjH0zGtbXrE1IsTg9ZC/bGflOy3k
adE2VW+9PmGxg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Sun, 27 Apr 2025 17:31:46 +0200
X-ME-IP: 90.112.40.65
Message-ID: <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
Date: Sun, 27 Apr 2025 17:31:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-27 14:59, Stefan Monnier wrote:
>>> Exactly, I fully agree, the question is "how to keep track of the
>>> children"?
>>
>> You could approximate it with `after-load-functions`. Or, with the
>> proposed patch, you could use an advice on `cl--type-deftype`. Once you
>> do that, you won't need to break circularity in `cl-types-of`.
>
> I think what I was trying to say all along is:
> the circularity you're trying to break doesn't come from `cl-deftype` or
> `cl-types-of` but from your impredicative definition of `T1`.
> So it'd be best to fix it there:
>
> (cl-deftype T1 ()
> `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))
>
> =>
>
> (defvar my-pending-T1-check (make-symbol "void"))
>
> (cl-deftype T1 ()
> `(satisfies
> ,(lambda (o)
> (and (not (eq o my-pending-T1-check))
> (let ((my-pending-T1-check o))
> (memq 'T1 (cl-types-of o)))))))
>
Hi Stefan,
I quite like this approach, where it's not `cl-types-of', but each type
that bears responsibility for its implementation.
So, if I understand correctly, your recommendation is to not try to solve
recursion (or other) problems in `cl-types-of' at all, but rather at the
level of each type's definition, and to let ill-defined types possibly
cause errors?
The only point that still bothers me is not protecting `cl-types-of' from
errors due to ill-defined types. This is particularly true because this
can impact the entire Emacs session if certain methods are prevented from
working, such as those involved in the display process (I use such methods
based on `cl-deftype' for example, in my own alternative implementation of
icons and tab-line).
If you agree I will update cl-types.el accordingly and dispatch it in
the existing libraries according to your previous proposal... to see what
happens ;-)
Thanks again for being so helpful!
David
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 28 Apr 2025 10:57:02 +0000
Resent-Message-ID: <handler.77725.B77725.174583781014778 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174583781014778
(code B ref 77725); Mon, 28 Apr 2025 10:57:02 +0000
Received: (at 77725) by debbugs.gnu.org; 28 Apr 2025 10:56:50 +0000
Received: from localhost ([127.0.0.1]:54501 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9MAL-0003qH-Ap
for submit <at> debbugs.gnu.org; Mon, 28 Apr 2025 06:56:50 -0400
Received: from smtp-73.smtpout.orange.fr ([80.12.242.73]:39753
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u9MAF-0003pz-Av
for 77725 <at> debbugs.gnu.org; Mon, 28 Apr 2025 06:56:47 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 9MA7u5rBB5k819MAAuffQ2; Mon, 28 Apr 2025 12:56:41 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745837801;
bh=naXhKEH5u/qmLNS5YEi6v6kda32w4lOtwMpJs0eu1bQ=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=DjQ8x7++PP9Mpu+1OkLxnSscouV/IxPJfSMHBmIL2IHFXFx+dsI1nZiCbwStXBcVI
yHgy03bWWFpqN7hgzCAA1GFz53NPZduUWBdMebihKjUoOO7X9Rcq8adyWBGL9gZ4a0
Vuy4TQ408zQJqBTnpSHNGocJKE2uXsZaU18v+Gh8QbcIA78qY1ojoemn5q/+Z6uAky
u/pENM0gASwAgZwbc4cnMIMl6GGX14S5fGBK/EGEEmTJEK+U+2U5YloXkIOhr5E0zS
Pf+d2QDqCU5ii4Zlcph3Ua/iSBgBj538cI5lfzCtGzxAdOPtz7IidcwQg9mam14+KA
RY8M/KV91qwEw==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Mon, 28 Apr 2025 12:56:41 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------IFhIYKTIZdYTv2nFCBYlduCU"
Message-ID: <86086316-6416-47c0-b7b5-42b84c25c5de@HIDDEN>
Date: Mon, 28 Apr 2025 12:56:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: David Ponce <da_vid@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------IFhIYKTIZdYTv2nFCBYlduCU
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2025-04-27 17:31, David Ponce wrote:
> On 2025-04-27 14:59, Stefan Monnier wrote:
>>>> Exactly, I fully agree, the question is "how to keep track of the
>>>> children"?
>>>
>>> You could approximate it with `after-load-functions`. Or, with the
>>> proposed patch, you could use an advice on `cl--type-deftype`. Once you
>>> do that, you won't need to break circularity in `cl-types-of`.
>>
>> I think what I was trying to say all along is:
>> the circularity you're trying to break doesn't come from `cl-deftype` or
>> `cl-types-of` but from your impredicative definition of `T1`.
>> So it'd be best to fix it there:
>>
>> (cl-deftype T1 ()
>> `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))
>>
>> =>
>>
>> (defvar my-pending-T1-check (make-symbol "void"))
>>
>> (cl-deftype T1 ()
>> `(satisfies
>> ,(lambda (o)
>> (and (not (eq o my-pending-T1-check))
>> (let ((my-pending-T1-check o))
>> (memq 'T1 (cl-types-of o)))))))
>>
>
> Hi Stefan,
>
> I quite like this approach, where it's not `cl-types-of', but each type
> that bears responsibility for its implementation.
>
> So, if I understand correctly, your recommendation is to not try to solve
> recursion (or other) problems in `cl-types-of' at all, but rather at the
> level of each type's definition, and to let ill-defined types possibly
> cause errors?
>
> The only point that still bothers me is not protecting `cl-types-of' from
> errors due to ill-defined types. This is particularly true because this
> can impact the entire Emacs session if certain methods are prevented from
> working, such as those involved in the display process (I use such methods
> based on `cl-deftype' for example, in my own alternative implementation of
> icons and tab-line).
>
> If you agree I will update cl-types.el accordingly and dispatch it in
> the existing libraries according to your previous proposal... to see what
> happens ;-)
>
> Thanks again for being so helpful!
>
> David
Please find attached a new version of cl-types.el, where any attempt to work
around type definition errors with `cl-types-of' has been removed. If such
an error occurs, it is now clearly signaled by `warn', and the affected type
is marked as "in error" and ignored until its next redefinition or deletion.
WDYT?
--------------IFhIYKTIZdYTv2nFCBYlduCU
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBEYXRhIHR5cGVzIGRlZmluZWQg
YnkgYGNsLWRlZnR5cGUnIGFyZSBub3cgcmVjb2duaXplZCBhcyBhcmd1bWVudAo7OyB0eXBl
cyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbnMgbWV0aG9kcy4KCjs7IFdpbGwg
YmUgcmVtb3ZlZCB3aGVuIGluY2x1ZGVkIGluIGNsLWxpYi4KKHJlcXVpcmUgJ2NsLWxpYikK
KGV2YWwtd2hlbi1jb21waWxlIChyZXF1aXJlICdjbC1tYWNzKSkgIDtGb3IgY2wtLWZpbmQt
Y2xhc3MuCgo7OyBFeHRlbmQgYGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdo
aWNoIGFyZSBhbHNvIHZhbGlkCjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBn
ZW5lcmljIGZ1bmN0aW9uIG1ldGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3Mu
Z251Lm9yZy9jZ2kvYnVncmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4g
ZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBu
ZXcgZGF0YSB0eXBlcy4KOzsKOzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IHJldHVybnMgdGhl
IHR5cGVzIGFuIG9iamVjdCBiZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5p
bAogICJMaXN0IG9mIGRlZmluZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0
Y2hpbmcuIikKCjs7IEZJWE1FOiBUaGUgYGNsLWRlZnR5cGUtaGFuZGxlcicgcHJvcGVydHkg
c2hvdWxkIGFyZ3VhYmx5IGJlIHR1cm5lZAo7OyBpbnRvIGEgZmllbGQgb2YgdGhpcyBzdHJ1
Y3QgKGJ1dCBpdCBoYXMgcGVyZm9ybWFuY2UgYW5kCjs7IGNvbXBhdGliaWxpdHkgaW1wbGlj
YXRpb25zLCBzbyBsZXQncyBub3QgbWFrZSB0aGF0IGNoYW5nZSBmb3Igbm93KS4KKGNsLWRl
ZnN0cnVjdAogICAgKGNsLXR5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNsYXNzKQog
ICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAoOmNvbnN0
cnVjdG9yIGNsLS10eXBlLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAg
ICAgICAgICAgICAgICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50
LXR5cGVzCiAgICAgICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAg
ICAgICAgICAgICAgIChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJk
YSAodHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGNsLS1maW5kLWNs
YXNzIHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiVW5r
bm93biB0eXBlOiAlUyIgdHlwZSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJl
bnQtdHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBm
b3IgdHlwZXMgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScuIikKCihkZWZ1biBjbC0tdHlwZS1w
IChvYmplY3QpCiAgIlJldHVybiBub24tbmlsIGlmIE9CSkVDVCBpcyBhIHVzZWQgZGVmaW5l
ZCB0eXBlLgpUaGF0IGlzLCBhIHR5cGUgb2YgY2xhc3MgYGNsLXR5cGUtY2xhc3MnLiIKICAo
YW5kIChzeW1ib2xwIG9iamVjdCkgKGNsLXR5cGUtY2xhc3MtcCAoY2wtLWZpbmQtY2xhc3Mg
b2JqZWN0KSkpKQoKKGRlZm1hY3JvIGNsLS10eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdldCBw
YXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGlu
ZyBhIHR5cGUuIgogIGAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNzICxu
YW1lKSkpCgooZGVmdW4gY2wtLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGlsZHJl
biBvZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5n
IGEgdHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNs
LWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogIChsZXQgKGNoaWxk
cmVuKQogICAgKGRvbGlzdCAoZWx0IGNsLS10eXBlLWxpc3QpCiAgICAgIChvciAoZXEgbmFt
ZSBlbHQpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSAoY2wtLXR5cGUtcGFyZW50cyBlbHQp
KQogICAgICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkK
CihkZWZ1biBjbC0tdHlwZS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxpc3Qg
b2YgZGVmaW5lZCB0eXBlcy4iCiAgKG1hcGNhciAobGFtYmRhICh0eXBlKSAoY2wtLXR5cGUt
cGFyZW50cyB0eXBlKSkgY2wtLXR5cGUtbGlzdCkpCgo7OyBLZWVwIGl0IGZvciBub3csIGZv
ciB0ZXN0aW5nLgooZGVmdW4gY2wtLXR5cGUtdW5kZWZpbmUgKG5hbWUpCiAgIlJlbW92ZSB0
aGUgZGVmaW5pdGlvbnMgb2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4gdW5xdW90ZWQg
c3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClNpZ25hbCBhbiBlcnJvciBpZiBvdGhlciB0
eXBlcyBpbmhlcml0IGZyb20gTkFNRS4iCiAgKGRlY2xhcmUtZnVuY3Rpb24gY2wtcmVtcHJv
cCAiY2wtZXh0cmEiIChzeW1ib2wgcHJvcG5hbWUpKQogIChjbC1jaGVjay10eXBlIG5hbWUg
KHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAod2hlbi1sZXQqICgoY2hpbGRyZW4gKGFuZCAo
Y2wtLXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0tdHlw
ZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMi
IGNoaWxkcmVuKSkKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXBy
b3AgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRl
bHEgbmFtZSBjbC0tdHlwZS1saXN0KSkpCgooZGVmdW4gY2wtLXR5cGUtZGVmdHlwZSAobmFt
ZSBwYXJlbnRzICZvcHRpb25hbCBkb2NzdHJpbmcpCiAgIkdlbmVyYWxpemUgdHlwZSB3aXRo
IE5BTUUgZm9yIG1ldGhvZCBkaXNwYXRjaGluZy4KUEFSRU5UUyBpcyBhIGxpc3Qgb2YgdHlw
ZXMgTkFNRSBpcyBhIHN1YnR5cGUgb2YsIG9yIG5pbC4KRE9DU1RSSU5HIGlzIGFuIG9wdGlv
bmFsIGRvY3VtZW50YXRpb24gc3RyaW5nLiIKICAobGV0ICgob2xkdGxpc3QgKGNvcHktc2Vx
dWVuY2UgY2wtLXR5cGUtbGlzdCkpCiAgICAgICAgKG9sZHBsaXN0IChjb3B5LXNlcXVlbmNl
IChzeW1ib2wtcGxpc3QgbmFtZSkpKSkKICAgIChjb25kaXRpb24tY2FzZSBlcnIKICAgICAg
ICAobGV0KiAoKGNsYXNzIChjbC0tZmluZC1jbGFzcyBuYW1lKSkKICAgICAgICAgICAgICAg
KHJlY29yZGVkIChtZW1xIG5hbWUgY2wtLXR5cGUtbGlzdCkpKQogICAgICAgICAgKGlmIChu
dWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVsbCByZWNvcmRlZCkKICAgICAgICAg
ICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVkLCBidXQgZG9lc24ndCBleGlzdCIp
KQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9yICJUeXBlIGV4aXN0cywgYnV0IG5v
dCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3IgKGNsLXR5cGUtY2xhc3MtcCBjbGFz
cykKICAgICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBhbm90aGVyIGNsYXNzOiAlUyIg
KHR5cGUtb2YgY2xhc3MpKSkpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSBwYXJlbnRzKQog
ICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykpCiAg
ICAgICAgICA7OyBTZXR1cCBhIHR5cGUgZGVzY3JpcHRvciBmb3IgTkFNRS4KICAgICAgICAg
IChzZXRmIChjbC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAgICAgKGNsLS10eXBl
LWNsYXNzLW1ha2UgbmFtZSBkb2NzdHJpbmcgcGFyZW50cykpCiAgICAgICAgICAoaWYgcmVj
b3JkZWQKICAgICAgICAgICAgICA7OyBDbGVhciBhbnkgcHJldmlvdXMgZXJyb3IgbWFyay4K
ICAgICAgICAgICAgICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tdHlwZS1lcnJvcikKICAgICAg
ICAgICAgOzsgUmVjb3JkIG5ldyB0eXBlIHRvIGluY2x1ZGUgaXRzIGRlcGVuZGVuY3kgaW4g
dGhlIERBRy4KICAgICAgICAgICAgKHB1c2ggbmFtZSBjbC0tdHlwZS1saXN0KSkKICAgICAg
ICAgIDs7IGBjbC10eXBlcy1vZicgaXRlcmF0ZXMgdGhyb3VnaCBhbGwga25vd24gdHlwZXMg
dG8gY29sbGVjdAogICAgICAgICAgOzsgYWxsIHRob3NlIGFuIG9iamVjdCBiZWxvbmdzIHRv
LCBzb3J0ZWQgZnJvbSB0aGUgbW9zdAogICAgICAgICAgOzsgc3BlY2lmaWMgdHlwZSB0byB0
aGUgbW9yZSBnZW5lcmFsIHR5cGUuICBTbywga2VlcCB0aGUKICAgICAgICAgIDs7IGdsb2Jh
bCBsaXN0IGluIHRoaXMgb3JkZXIuCiAgICAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0CiAg
ICAgICAgICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAgICAgICAgIChj
bC0tdHlwZS1kYWcpCiAgICAgICAgICAgICAgICAgKGxhbWJkYSAoXykgKGVycm9yICJJbnZh
bGlkIGRlcGVuZGVuY3kgZ3JhcGgiKSkpKSkKICAgICAgKGVycm9yCiAgICAgICA7OyBPbiBl
cnJvciByZXN0b3JlIHByZXZpb3VzIGRhdGEuCiAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0
IG9sZHRsaXN0KQogICAgICAgKHNldGYgKHN5bWJvbC1wbGlzdCBuYW1lKSBvbGRwbGlzdCkK
ICAgICAgIChlcnJvciAoZm9ybWF0ICJEZWZpbmUgJVMgZmFpbGVkOiAlcyIKICAgICAgICAg
ICAgICAgICAgICAgIG5hbWUgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikpKSkpKSkKCjs7
OyMjI2F1dG9sb2FkCihkZWZtYWNybyBjbC1kZWZ0eXBlMiAobmFtZSBhcmdsaXN0ICZyZXN0
IGJvZHkpCiAgIkRlZmluZSBOQU1FIGFzIGEgbmV3IGRhdGEgdHlwZS4KVGhlIHR5cGUgTkFN
RSBjYW4gdGhlbiBiZSB1c2VkIGluIGBjbC10eXBlY2FzZScsIGBjbC1jaGVjay10eXBlJywK
ZXRjLiwgYW5kIGFzIGFyZ3VtZW50IHR5cGUgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVu
Y3Rpb24gbWV0aG9kcy4KCkFSR0xJU1QgaXMgYSBDb21tb24gTGlzcCBhcmd1bWVudCBsaXN0
IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5CmBjbC1kZWZtYWNybycuICBCT0RZIGZvcm1zIGFy
ZSBldmFsdWF0ZWQgYW5kIHNob3VsZCByZXR1cm4gYSB0eXBlCnNwZWNpZmllciB0aGF0IGlz
IGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUgKHNlZSB0aGUgSW5mbyBub2RlIGAoY2wpIFR5cGUK
UHJlZGljYXRlcycgaW4gdGhlIEdOVSBFbWFjcyBDb21tb24gTGlzcCBFbXVsYXRpb24gbWFu
dWFsKS4KCklmIHRoZXJlIGlzIGEgYGRlY2xhcmUnIGZvcm0gaW4gQk9EWSwgdGhlIHNwZWMg
KHBhcmVudHMgUEFSRU5UUykgaXMKcmVjb2duaXplZCB0byBzcGVjaWZ5IGEgbGlzdCBvZiB0
eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZi4gIEZvcgppbnN0YW5jZToKCiAgKGNsLWRlZnR5
cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25hbCBiaXRzKQogICAgXCJVbnNpZ25lZCBpbnRl
Z2VyLlwiCiAgICAobGlzdCBcXD0naW50ZWdlciAwIChpZiAoZXEgYml0cyBcXD0nKikgYml0
cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtOGJpdHMg
KCkKICAgIFwiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuXCIKICAgIChkZWNsYXJlIChwYXJl
bnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNpZ25lZC1ieXRlIDgpKQoKVGhlIGxp
c3Qgb2YgUEFSRU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRoZSBvcmRlciBvZiBtZXRob2RzIGlu
dm9jYXRpb24sCmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5IGNhdXNlIGluY29ycmVjdCBvcmRl
cmluZyBvZiBtZXRob2RzLCB3aGlsZQpleHRyYW5lb3VzIFBBUkVOVFMgbWF5IGNhdXNlIHVz
ZSBvZiBleHRyYW5lb3VzIG1ldGhvZHMuCgpJZiBQQVJFTlRTIGlzIG5vbi1uaWwsIEFSR0xJ
U1QgbXVzdCBiZSBuaWwuIgogIChkZWNsYXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1z
dHJpbmcgMykgKGluZGVudCAyKSkKICAocGNhc2UtbGV0KgogICAgICAoKGAoLGRlY2xzIC4g
LGZvcm1zKSAobWFjcm9leHAtcGFyc2UtYm9keSBib2R5KSkKICAgICAgIChkb2NzdHJpbmcg
KGlmIChzdHJpbmdwIChjYXIgZGVjbHMpKQogICAgICAgICAgICAgICAgICAgICAgKGNhciBk
ZWNscykKICAgICAgICAgICAgICAgICAgICAoY2FkciAoYXNzcSA6ZG9jdW1lbnRhdGlvbiBk
ZWNscykpKSkKICAgICAgIChwYXJlbnRzIChjZHIgKGFzc3EgJ3BhcmVudHMgKGNkciAoYXNz
cSAnZGVjbGFyZSBkZWNscykpKSkpKQogICAgKGFuZCBwYXJlbnRzIGFyZ2xpc3QKICAgICAg
ICAgKGVycm9yICJQYXJlbnRzIHNwZWNpZmllZCwgYnV0IGFyZ2xpc3Qgbm90IGVtcHR5Iikp
CiAgICAoaWYgZG9jc3RyaW5nIChzZXRxIGZvcm1zIChjb25zIGRvY3N0cmluZyBmb3Jtcykp
KQogICAgYChldmFsLWFuZC1jb21waWxlIDs7Y2wtZXZhbC13aGVuIChjb21waWxlIGxvYWQg
ZXZhbCkKICAgICAgIChjbC0tdHlwZS1kZWZ0eXBlICcsbmFtZSAnLHBhcmVudHMgLGRvY3N0
cmluZykKICAgICAgIChkZWZpbmUtc3ltYm9sLXByb3AgJyxuYW1lICdjbC1kZWZ0eXBlLWhh
bmRsZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNsLWZ1bmN0aW9uCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAobGFtYmRhICgmY2wtZGVmcyAoJyopICxAYXJnbGlzdCkK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLEBmb3JtcykpKSkpKQoKOzsgRW5zdXJl
IGVhY2ggdHlwZSBzYXRpc2ZpZXMgYGVxbCcuCihkZWZ2YXIgY2wtLXR5cGUtdW5pcXVlICht
YWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxdWFsKQogICJSZWNvcmQgYW4gdW5pcXVlIHZhbHVl
IG9mIGVhY2ggdHlwZS4iKQoKKGRlZnVuIGNsLS10eXBlLWVycm9yICh0eXBlIGVycm9yKQog
ICJNYXJrIFRZUEUgYXMgaW4tZXJyb3IsIGFuZCByZXBvcnQgdGhlIHByb2R1Y2VkIEVSUk9S
IHZhbHVlLiIKICAocHV0IHR5cGUgJ2NsLS10eXBlLWVycm9yIGVycm9yKSA7OyBNYXJrIFRZ
UEUgYXMgaW4tZXJyb3IuCiAgOzsgVGVtcG9yYXJpbHkgcmFpc2UgdGhlIHJlY3Vyc2lvbiBs
aW1pdCB0byBhdm9pZCBhbm90aGVyIHJlY3Vyc2lvbgogIDs7IGVycm9yIHdoaWxlIHJlcG9y
dGluZyBFUlJPUi4KICAobGV0ICgobWF4LWxpc3AtZXZhbC1kZXB0aCAoKyA4MDAgbWF4LWxp
c3AtZXZhbC1kZXB0aCkpKQogICAgKHdhcm4gICJjbC10eXBlcy1vZiAlcywgJXMiIHR5cGUg
KGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycm9yKSkpCiAgbmlsKQoKOzsgRklYTUU6IGBjbC10
eXBlcy1vZicgQ1BVIGNvc3QgaXMgcHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2YgdHlw
ZXMKOzsgZGVmaW5lZCB3aXRoIGBjbC1kZWZ0eXBlJywgc28gdGhlIG1vcmUgcG9wdWxhciBp
dCBnZXRzLCB0aGUgc2xvd2VyCjs7IGl0IGJlY29tZXMuICBBbmQgb2YgY291cnNlLCB0aGUg
Y29zdCBvZiBlYWNoIHR5cGUgY2hlY2sgaXMKOzsgdW5ib3VuZGVkLCBzbyBhIHNpbmdsZSAi
ZXhwZW5zaXZlIiB0eXBlIGNhbiBzbG93IGV2ZXJ5dGhpbmcgZG93bgo7OyBmdXJ0aGVyLgo7
Owo7OyBUaGUgdXN1YWwgZGlzcGF0Y2ggaXMKOzsKOzsgICAobGFtYmRhIChhcmcgJnJlc3Qg
YXJncykKOzsgICAgIChsZXQgKChmIChnZXRoYXNoIChjbC10eXBlb2YgYXJnKSBwcmVjb21w
dXRlZC1tZXRob2RzLXRhYmxlKSkpCjs7ICAgICAgIChpZiBmCjs7ICAgICAgICAgICAoYXBw
bHkgZiBhcmcgYXJncykKOzsgICAgICAgICA7OyBTbG93IGNhc2Ugd2hlbiBlbmNvdW50ZXJp
bmcgYSBuZXcgdHlwZQo7OyAgICAgICAgIC4uLikpKQo7Owo7OyB3aGVyZSBvZnRlbiB0aGUg
bW9zdCBleHBlbnNpdmUgcGFydCBpcyBgJnJlc3QnICh3aGljaCBoYXMgdG8KOzsgYWxsb2Nh
dGUgYSBsaXN0IGZvciB0aG9zZSByZW1haW5pbmcgYXJndW1lbnRzKSwKOzsKOzsgU28gd2Un
cmUgdGFsa2luZyBhYm91dCByZXBsYWNpbmcKOzsKOzsgICAmcmVzdCArIGNsLXR5cGUtb2Yg
KyBnZXRoYXNoICsgaWYgKyBhcHBseQo7Owo7OyB3aXRoIGEgZnVuY3Rpb24gdGhhdCBsb29w
cyBvdmVyIE4gdHlwZXMsIGNhbGxpbmcgYGNsLXR5cGVwJyBvbiBlYWNoCjs7IG9uZSBvZiB0
aGVtIChgY2wtdHlwZXAnIGl0c2VsZiBiZWluZyBhIHJlY3Vyc2l2ZSBmdW5jdGlvbiB0aGF0
Cjs7IGJhc2ljYWxseSBpbnRlcnByZXRzIHRoZSB0eXBlIGxhbmd1YWdlKS4gIFRoaXMgaXMg
Z29pbmcgdG8gc2xvdwo7OyBkb3duIGRpc3BhdGNoIHZlcnkgc2lnbmlmaWNhbnRseSBmb3Ig
dGhvc2UgZ2VuZXJpYyBmdW5jdGlvbnMgdGhhdAo7OyBoYXZlIGEgbWV0aG9kIHRoYXQgZGlz
cGF0Y2hlcyBvbiBhIHVzZXIgZGVmaW5lZCB0eXBlLCBjb21wYXJlZCB0bwo7OyB0aG9zZSB0
aGF0IGRvbid0Lgo7Owo7OyBBIHBvc3NpYmxlIGZ1cnRoZXIgaW1wcm92ZW1lbnQ6Cjs7Cjs7
IC0gYmFzZWQgb24gdGhlIFBBUkVOVFMgZGVjbGFyYXRpb24sIGNyZWF0ZSBhIG1hcCBmcm9t
IGJ1aWx0aW4tdHlwZQo7OyAgIHRvIHRoZSBzZXQgb2YgY2wtdHlwZXMgdGhhdCBoYXZlIHRo
YXQgYnVpbHRpbi10eXBlIGFtb25nIHRoZWlyCjs7ICAgcGFyZW50cy4gIFRoYXQgcHJlc3Vt
ZXMgc29tZSBQQVJFTlRTIGluY2x1ZGUgc29tZSBidWlsdGluLXR5cGVzLAo7OyAgIG9idmlv
dXNseSBvdGhlcndpc2UgdGhlIG1hcCB3aWxsIGJlIHRyaXZpYWwgd2l0aCBhbGwgY2wtdHlw
ZXMKOzsgICBhc3NvY2lhdGVkIHdpdGggdGhlIGB0JyAiZHVtbXkgcGFyZW50Ii4gIFsgV2Ug
Y291bGQgZXZlbiBnbyBjcmF6eQo7OyAgIGFuZCB0cnkgYW5kIGd1ZXNzIFBBUkVOVFMgd2hl
biBub3QgcHJvdmlkZWQsIGJ5IGFuYWx5emluZyB0aGUKOzsgICB0eXBlJ3MgZGVmaW5pdGlv
bi4gXQo7Owo7OyAtIGluIGBjbC10eXBlcy1vZicgc3RhcnQgYnkgY2FsbGluZyBgY2wtdHlw
ZS1vZicsIHRoZW4gdXNlIHRoZSBtYXAKOzsgICB0byBmaW5kIHdoaWNoIGNsLXR5cGVzIG1h
eSBuZWVkIHRvIGJlIGNoZWNrZWQuCjs7CihkZWZ1biBjbC10eXBlcy1vZiAob2JqZWN0KQog
ICJSZXR1cm4gdGhlIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLgpSZXR1cm4gYW4gdW5pcXVl
IGxpc3Qgb2YgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8sIG9yZGVyZWQgZnJvbSB0aGUKbW9z
dCBzcGVjaWZpYyB0eXBlIHRvIHRoZSBtb3N0IGdlbmVyYWwuIgogIChsZXQgKChmb3VuZCAo
bGlzdCAoY2wtLXR5cGUtcGFyZW50cyAoY2wtdHlwZS1vZiBvYmplY3QpKSkpKQogICAgOzsg
QnVpbGQgYSBEQUcgb2YgYWxsIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLgogICAgKGRvbGlz
dCAodHlwZSBjbC0tdHlwZS1saXN0KQogICAgICAoYW5kCiAgICAgICA7OyBTa2lwIHR5cGUs
IGlmIGl0IHByZXZpb3VzbHkgcHJvZHVjZWQgYW4gZXJyb3IuCiAgICAgICAobnVsbCAoZ2V0
IHR5cGUgJ2NsLS10eXBlLWVycm9yKSkKICAgICAgIDs7IFNraXAgdHlwZSBub3QgZGVmaW5l
ZCBieSBgY2wtZGVmdHlwZScuCiAgICAgICAoY2wtdHlwZS1jbGFzcy1wIChjbC0tZmluZC1j
bGFzcyB0eXBlKSkKICAgICAgIDs7IElmIEJBUiBpcyBkZWNsYXJlZCBhcyBhIHBhcmVudCBv
ZiBGT08gYW5kIGBjbC10eXBlcy1vZicgaGFzCiAgICAgICA7OyBhbHJlYWR5IGRlY2lkZWQg
dGhhdCB0aGUgdmFsdWUgaXMgb2YgdHlwZSBGT08sIHRoZW4gd2UKICAgICAgIDs7IGFscmVh
ZHkga25vdyBCQVIgd2lsbCBiZSBpbiB0aGUgb3V0cHV0IGFueXdheSBhbmQgdGhlcmUncyBu
bwogICAgICAgOzsgcG9pbnQgdGVzdGluZyBCQVIuICBTbywgc2tpcCB0eXBlIGFscmVhZHkg
c2VsZWN0ZWQgYXMgcGFyZW50CiAgICAgICA7OyBvZiBhbm90aGVyIHR5cGUsIGFzc3VtaW5n
IHRoYXQsIG1vc3Qgb2YgdGhlIHRpbWUsIGBhc3NxJwogICAgICAgOzsgd2lsbCBiZSBmYXN0
ZXIgdGhhbiBgY2wtdHlwZXAnLgogICAgICAgKG51bGwgKGFzc3EgdHlwZSBmb3VuZCkpCiAg
ICAgICA7OyBJZiBPQkpFQ1QgaXMgb2YgdHlwZSwgYWRkIHR5cGUgYW5kIGl0cyBwYXJlbnRz
IHRvIHRoZSBEQUcuCiAgICAgICAoY29uZGl0aW9uLWNhc2UgZQogICAgICAgICAgIChjbC10
eXBlcCBvYmplY3QgdHlwZSkKICAgICAgICAgKGVycm9yIChjbC0tdHlwZS1lcnJvciB0eXBl
IGUpKSkKICAgICAgIDs7IChkb2xpc3QgKHAgKGNsLS10eXBlLXBhcmVudHMgdHlwZSkpCiAg
ICAgICA7OyAgIChwdXNoIChjbC0tdHlwZS1wYXJlbnRzIHApIGZvdW5kKSkKICAgICAgIDs7
IEVxdWl2YWxlbnQgdG8gdGhlIGBkb2xpc3QnIGFib3ZlLCBidXQgZmFzdGVyOiBhdm9pZCB0
bwogICAgICAgOzsgcmVjb21wdXRlIHNldmVyYWwgbGlzdHMgb2YgcGFyZW50cyB3ZSBhbHJl
YWR5IGtub3cuCiAgICAgICAobGV0ICgocGwgKGNsLS10eXBlLXBhcmVudHMgdHlwZSkpKQog
ICAgICAgICAod2hpbGUgcGwKICAgICAgICAgICAocHVzaCBwbCBmb3VuZCkKICAgICAgICAg
ICAoc2V0cSBwbCAoY2RyIHBsKSkpKSkpCiAgICA7OyBDb21wdXRlIGFuIG9yZGVyZWQgbGlz
dCBvZiB0eXBlcyBmcm9tIHRoZSBjb2xsZWN0ZWQgREFHLgogICAgKHNldHEgZm91bmQgKG1l
cmdlLW9yZGVyZWQtbGlzdHMgZm91bmQpKQogICAgOzsgUmV0dXJuIGFuIHVuaXF1ZSB2YWx1
ZSBvZiB0aGlzIGxpc3Qgb2YgdHlwZXMsIHdoaWNoIGlzIGFsc28gdGhlCiAgICA7OyBsaXN0
IG9mIHNwZWNpZmllcnMgZm9yIHRoaXMgdHlwZS4KICAgICh3aXRoLW1lbW9pemF0aW9uIChn
ZXRoYXNoIGZvdW5kIGNsLS10eXBlLXVuaXF1ZSkKICAgICAgZm91bmQpKSkKCjs7OyBNZXRo
b2QgZGlzcGF0Y2hpbmcKOzsKKGNsLWdlbmVyaWMtZGVmaW5lLWdlbmVyYWxpemVyIGNsLS10
eXBlLWdlbmVyYWxpemVyCiAgMjAgOzsgInR5cGVvZiIgPCAiY2wtdHlwZXMtb2YiIDwgImhl
YWQiIHByaW9yaXR5CiAgKGxhbWJkYSAob2JqICZyZXN0IF8pIGAoY2wtdHlwZXMtb2YgLG9i
aikpCiAgKGxhbWJkYSAodGFnICZyZXN0IF8pIChpZiAoY29uc3AgdGFnKSB0YWcpKSkKCihj
bC1kZWZtZXRob2QgY2wtZ2VuZXJpYy1nZW5lcmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1v
ZiIgKHR5cGUpCiAgIlN1cHBvcnQgZm9yIGRpc3BhdGNoIG9uIHR5cGVzLiIKICAoaWYgKGNs
LS10eXBlLXAgdHlwZSkKICAgICAgKGxpc3QgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIpCiAgICAo
Y2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoKKHByb3ZpZGUgJ2NsLXR5cGVzKQoKOzs7IGNsLXR5
cGVzLmVsIGVuZHMgaGVyZQo=
--------------IFhIYKTIZdYTv2nFCBYlduCU--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 28 Apr 2025 21:46:08 +0000
Resent-Message-ID: <handler.77725.B77725.174587672310633 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174587672310633
(code B ref 77725); Mon, 28 Apr 2025 21:46:08 +0000
Received: (at 77725) by debbugs.gnu.org; 28 Apr 2025 21:45:23 +0000
Received: from localhost ([127.0.0.1]:37380 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9WHu-0002l3-GU
for submit <at> debbugs.gnu.org; Mon, 28 Apr 2025 17:45:23 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54729)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u9WHg-0002cV-5D
for 77725 <at> debbugs.gnu.org; Mon, 28 Apr 2025 17:45:13 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8B727442895;
Mon, 28 Apr 2025 17:44:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745876690;
bh=jW4Hc+jcpsO+RgPkPzYgVz+Eth2Xm920adTwRPPlmIs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=o7MWMNEQJ2D0z91X3LNtzTrTtlgycpUlkU0lsXiENhR90bFKJlNscuxFywCylUvPd
IBvu6cEO7OeLpX+lKaaeiqUARtSfdRRuWM1Z1xtfKFEnUlmLzhsuJ3MyosYj6oQxD1
xSf/Bddv63040kMc3g/vOdXWTCsNqvwmggVmDNQFNYPvG/Zfm1aGxlOZqAbgcynjjJ
ktnZPttyTgxfRZ0MctZGdae35Y1Si5g7j7tulBxrLDpOu7OLo765NkO3PrHw2LoE3d
gVyqHq1K1M15FuPTKFdqVm2qKDfBOEWyHDFLlrRoJLAVxiDhgTJ5EoPHo3wbBOP5Zy
13j3nbdsdfN8Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BDCF444274B;
Mon, 28 Apr 2025 17:44:50 -0400 (EDT)
Received: from asado (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 99A0E12063D;
Mon, 28 Apr 2025 17:44:50 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
Message-ID: <jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
Date: Mon, 28 Apr 2025 17:44:49 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.214 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
> I quite like this approach, where it's not `cl-types-of', but each type
> that bears responsibility for its implementation.
Usually, I like to solve a problem centrally so it's done once and for
all, but here the problem is that breaking recursion is tricky business
which may need to be done in different ways in different cases, and on
top of that it's a fairly rare need, so I think in this case dumping the
responsibility onto those rare users of circularity in types is the
right tradeoff.
> So, if I understand correctly, your recommendation is to not try to solve
> recursion (or other) problems in `cl-types-of' at all, but rather at the
> level of each type's definition, and to let ill-defined types possibly
> cause errors?
Basically, yes.
> The only point that still bothers me is not protecting `cl-types-of' from
> errors due to ill-defined types. This is particularly true because this
> can impact the entire Emacs session if certain methods are prevented from
> working, such as those involved in the display process (I use such methods
> based on `cl-deftype' for example, in my own alternative implementation of
> icons and tab-line).
Fair enough.
I pushed your new code to the `scratch/cl-types` branch in `emacs.git`.
I haven't integrated it into the other CL-Lib files yet.
See patch below for comments on your code.
Stefan
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=cl-types.patch
diff --git a/lisp/emacs-lisp/cl-types.el b/lisp/emacs-lisp/cl-types.el
index 0a384e09d79..830acb1ff0c 100644
--- a/lisp/emacs-lisp/cl-types.el
+++ b/lisp/emacs-lisp/cl-types.el
@@ -46,12 +46,13 @@ cl--type-p
That is, a type of class `cl-type-class'."
(and (symbolp object) (cl-type-class-p (cl--find-class object))))
-(defmacro cl--type-parents (name)
+(defmacro cl--type-parents (name) ;FIXME: Make it a `defun' or `defsubst'!
"Get parents of type with NAME.
NAME is a symbol representing a type."
`(cl--class-allparents (cl--find-class ,name)))
(defun cl--type-children (name)
+ ;; FIXME: Isn't that he same as `cl--class-children'?
"Get children of the type with NAME.
NAME is a symbol representing a type.
Return a possibly empty list of types."
@@ -82,6 +83,7 @@ cl--type-undefine
(setq cl--type-list (delq name cl--type-list)))
(defun cl--type-deftype (name parents &optional docstring)
+ ;; FIXME: Should we also receive the arglist?
"Generalize type with NAME for method dispatching.
PARENTS is a list of types NAME is a subtype of, or nil.
DOCSTRING is an optional documentation string."
@@ -95,8 +97,13 @@ cl--type-deftype
(error "Type generalized, but doesn't exist"))
(or recorded (error "Type exists, but not generalized"))
(or (cl-type-class-p class)
+ ;; FIXME: We have some uses `cl-deftype' in Emacs that
+ ;; "complement" another declaration of the same type, so
+ ;; maybe we should turn this into a warning (and not overwrite
+ ;; the `cl--find-class' in that case)?
(error "Type in another class: %S" (type-of class))))
(if (memq name parents)
+ ;; FIXME: This test should be performed in the macro not here.
(error "Type in parents: %S" parents))
;; Setup a type descriptor for NAME.
(setf (cl--find-class name)
@@ -110,12 +117,21 @@ cl--type-deftype
;; all those an object belongs to, sorted from the most
;; specific type to the more general type. So, keep the
;; global list in this order.
+ ;; FIXME: This global operation is a bit worrisome, because it
+ ;; scales poorly with the number of types. I guess it's OK
+ ;; for now because `cl-deftype' is not very popular, but it'll
+ ;; probably need to be replaced at some point. Maybe we
+ ;; should simply require that the parents be defined already,
+ ;; then we can just `push' the new type, knowing it's in
+ ;; topological order by construction.
(setq cl--type-list
(merge-ordered-lists
(cl--type-dag)
(lambda (_) (error "Invalid dependency graph")))))
(error
;; On error restore previous data.
+ ;; FIXME: `cl--type-list' has not been changed yet at this point, AFAIK,
+ ;; so restoring with `oldtlist' is always redundant.
(setq cl--type-list oldtlist)
(setf (symbol-plist name) oldplist)
(error (format "Define %S failed: %s"
@@ -155,16 +171,27 @@ cl-deftype2
((`(,decls . ,forms) (macroexp-parse-body body))
(docstring (if (stringp (car decls))
(car decls)
- (cadr (assq :documentation decls))))
- (parents (cdr (assq 'parents (cdr (assq 'declare decls))))))
+ (cadr (assq :documentation decls))))
+ (declares (assq 'declare decls))
+ (parent-decl (assq 'parents (cdr declares)))
+ (parents (cdr parent-decl)))
+ (when parent-decl
+ ;; "Consume" the `parents' declaration.
+ (cl-callf (lambda (x) (delq parent-decl x)) (cdr declares))
+ (when (equal declares '(declare))
+ (cl-callf (lambda (x) (delq declares x)) decls)))
(and parents arglist
(error "Parents specified, but arglist not empty"))
- (if docstring (setq forms (cons docstring forms)))
`(eval-and-compile ;;cl-eval-when (compile load eval)
+ ;; FIXME: Where should `cl--type-deftype' go? Currently, code
+ ;; using `cl-deftype' can use (eval-when-compile (require 'cl-lib)),
+ ;; so `cl--type-deftype' needs to go either to `cl-preloaded.el'
+ ;; or it should be autoloaded even when `cl-lib' is not loaded.
(cl--type-deftype ',name ',parents ,docstring)
(define-symbol-prop ',name 'cl-deftype-handler
(cl-function
(lambda (&cl-defs ('*) ,@arglist)
+ ,@decls
,@forms))))))
;; Ensure each type satisfies `eql'.
@@ -226,6 +253,9 @@ cl-types-of
"Return the types OBJECT belongs to.
Return an unique list of types OBJECT belongs to, ordered from the
most specific type to the most general."
+ ;; FIXME: The current implementation of `cl--type-parents' is
+ ;; moderately expensive, so we should probably avoid calling it
+ ;; before we do the `gethash'.
(let ((found (list (cl--type-parents (cl-type-of object)))))
;; Build a DAG of all types OBJECT belongs to.
(dolist (type cl--type-list)
@@ -242,6 +272,9 @@ cl-types-of
;; will be faster than `cl-typep'.
(null (assq type found))
;; If OBJECT is of type, add type and its parents to the DAG.
+ ;; FIXME: This `condition-case' will make it harder to get a backtrace
+ ;; to debug the error in the type definition. So maybe
+ ;; use `condition-case-unless-debug'.
(condition-case e
(cl-typep object type)
(error (cl--type-error type e)))
@@ -254,11 +287,10 @@ cl-types-of
(push pl found)
(setq pl (cdr pl))))))
;; Compute an ordered list of types from the collected DAG.
- (setq found (merge-ordered-lists found))
;; Return an unique value of this list of types, which is also the
;; list of specifiers for this type.
(with-memoization (gethash found cl--type-unique)
- found)))
+ (merge-ordered-lists found))))
;;; Method dispatching
;;
--=-=-=--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Apr 2025 10:51:02 +0000
Resent-Message-ID: <handler.77725.B77725.17459238426245 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17459238426245
(code B ref 77725); Tue, 29 Apr 2025 10:51:02 +0000
Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 10:50:42 +0000
Received: from localhost ([127.0.0.1]:50770 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9iXx-0001cd-FJ
for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 06:50:42 -0400
Received: from smtp-80.smtpout.orange.fr ([80.12.242.80]:55773
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u9iXq-0001b8-Jw
for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 06:50:39 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 9iXkuM3e5eSp19iXnuVYKA; Tue, 29 Apr 2025 12:50:32 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745923832;
bh=3IehPu/4LKRlHsEIvUVyLuKclROKWkZi1s+5m5BQTkI=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=KaJFhqBvC4ow3UpbqIL+QplvJ0HEH22VovFPTSbgiw0NATyIOm7p3xVr0cgFdJsD+
p7I88raMjPyPk6GsW7L2VWyxsCqr/HtO5p/EfKvrAXeafflROMwhJ6qxvu68g/Fo54
UIulV8qYV6wGxzxStYdkJpXx0eBs6223nEOnZHwqG9gkkS3dWPgaIIzXjp3foLwcoR
rRk/4Ky3UmqMQDupx00baMRcbXmHzIJaAXycBvAnoGOjPTmfliXufShySYjQEiO2fy
wQp0fLrlhHCMwp35cPKOfiV3uKt16bjopGYHFfqAALo/ugzo8xu6wGFNXdid32tnyL
9EwVFY73BLjOg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Tue, 29 Apr 2025 12:50:32 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------wX7ISlduev3upoIOjvky26gv"
Message-ID: <bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
Date: Tue, 29 Apr 2025 12:50:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
<jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------wX7ISlduev3upoIOjvky26gv
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2025-04-28 23:44, Stefan Monnier wrote:
[...]
> I pushed your new code to the `scratch/cl-types` branch in `emacs.git`.
> I haven't integrated it into the other CL-Lib files yet.
> See patch below for comments on your code.
Merci!
Please find attached a new version of cl-types.el with some updates
following your comments.
Regarding this FIXME, in `cl--type-deftype', about the global setting
of `cl--type-list':
;; FIXME: This global operation is a bit worrisome, because it
;; scales poorly with the number of types. I guess it's OK
;; for now because `cl-deftype' is not very popular, but it'll
;; probably need to be replaced at some point. Maybe we
;; should simply require that the parents be defined already,
;; then we can just `push' the new type, knowing it's in
;; topological order by construction.
It's not clear to me how "simply require that the parents be defined
already", makes the new type "in topological order by construction".
Also, as all this is done only at type (re)definition, which should
not happen so often, I am curious to know why you think "this global
operation is a bit worrisome"?
In `cl-types-of', I liked your idea to avoid calls to
`cl--type-parents' and `merge-ordered-list' before we do the
`gethash'. I've gone a bit further in this direction (hopefully not
too far!) by doing all the type list computation just before creating
a new entry in the hash table. There's a slight overhead to determine
the types of objects not yet processed, but determining the types of
similar objects should be faster, which should be the most common case
(or at least the one to favor) when using types to dispatch methods.
WDYT?
Thanks!
David
--------------wX7ISlduev3upoIOjvky26gv
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBEYXRhIHR5cGVzIGRlZmluZWQg
YnkgYGNsLWRlZnR5cGUnIGFyZSBub3cgcmVjb2duaXplZCBhcyBhcmd1bWVudAo7OyB0eXBl
cyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbnMgbWV0aG9kcy4KCjs7IE5lZWRl
ZCB1bnRpbCBtZXJnZWQgaW4gZXhpc3RpbmcgbGlicmFyaWVzLgoocmVxdWlyZSAnY2wtbGli
KQooZXZhbC13aGVuLWNvbXBpbGUgKHJlcXVpcmUgJ2NsLW1hY3MpKSAgO0ZvciBjbC0tZmlu
ZC1jbGFzcy4KKGRlY2xhcmUtZnVuY3Rpb24gY2wtcmVtcHJvcCAiY2wtZXh0cmEiIChzeW1i
b2wgcHJvcG5hbWUpKQooZGVjbGFyZS1mdW5jdGlvbiBjbC0tY2xhc3MtY2hpbGRyZW4gImNs
LWV4dHJhIiAoY2xhc3MpKQoKOzsgRXh0ZW5kIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgZGF0
YSB0eXBlcyB3aGljaCBhcmUgYWxzbyB2YWxpZAo7OyBhcmd1bWVudCB0eXBlcyBmb3IgZGlz
cGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbiBtZXRob2RzIChzZWUgYWxzbwo7OyA8aHR0cHM6
Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1Z3JlcG9ydC5jZ2k/YnVnPTc3NzI1PikuCjs7Cjs7
IFRoZSBtYWluIGVudHJ5IHBvaW50cyBhcmU6Cjs7Cjs7IC0gYGNsLWRlZnR5cGUnLCB0aGF0
IGRlZmluZXMgbmV3IGRhdGEgdHlwZXMuCjs7Cjs7IC0gYGNsLXR5cGVzLW9mJywgdGhhdCBy
ZXR1cm5zIHRoZSB0eXBlcyBhbiBvYmplY3QgYmVsb25ncyB0by4KCihkZWZ2YXIgY2wtLXR5
cGUtbGlzdCBuaWwKICAiTGlzdCBvZiBkZWZpbmVkIHR5cGVzIHRvIGxvb2t1cCBmb3IgbWV0
aG9kIGRpc3BhdGNoaW5nLiIpCgo7OyBGSVhNRTogVGhlIGBjbC1kZWZ0eXBlLWhhbmRsZXIn
IHByb3BlcnR5IHNob3VsZCBhcmd1YWJseSBiZSB0dXJuZWQKOzsgaW50byBhIGZpZWxkIG9m
IHRoaXMgc3RydWN0IChidXQgaXQgaGFzIHBlcmZvcm1hbmNlIGFuZAo7OyBjb21wYXRpYmls
aXR5IGltcGxpY2F0aW9ucywgc28gbGV0J3Mgbm90IG1ha2UgdGhhdCBjaGFuZ2UgZm9yIG5v
dykuCihjbC1kZWZzdHJ1Y3QKICAgIChjbC10eXBlLWNsYXNzCiAgICAgKDppbmNsdWRlIGNs
LS1jbGFzcykKICAgICAoOm5vaW5saW5lIHQpCiAgICAgKDpjb25zdHJ1Y3RvciBuaWwpCiAg
ICAgKDpjb25zdHJ1Y3RvciBjbC0tdHlwZS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAg
ICAobmFtZQogICAgICAgICAgICAgICAgICAgIGRvY3N0cmluZwogICAgICAgICAgICAgICAg
ICAgIHBhcmVudC10eXBlcwogICAgICAgICAgICAgICAgICAgICZhdXggKHBhcmVudHMKICAg
ICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgIChsYW1iZGEgKHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9yIChj
bC0tZmluZC1jbGFzcyB0eXBlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo
ZXJyb3IgIlVua25vd24gdHlwZTogJVMiIHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcGFyZW50LXR5cGVzKSkpKQogICAgICg6Y29waWVyIG5pbCkpCiAgIlR5cGUgZGVz
Y3JpcHRvcnMgZm9yIHR5cGVzIGRlZmluZWQgYnkgYGNsLWRlZnR5cGUnLiIpCgooZGVmdW4g
Y2wtLXR5cGUtcCAob2JqZWN0KQogICJSZXR1cm4gbm9uLW5pbCBpZiBPQkpFQ1QgaXMgYSBj
bC10eXBlLgpUaGF0IGlzLCBhIHR5cGUgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScsIG9mIGNs
YXNzIGBjbC10eXBlLWNsYXNzJy4iCiAgKGFuZCAoc3ltYm9scCBvYmplY3QpIChjbC10eXBl
LWNsYXNzLXAgKGNsLS1maW5kLWNsYXNzIG9iamVjdCkpKSkKCihkZWZzdWJzdCBjbC0tdHlw
ZS1wYXJlbnRzIChuYW1lKQogICJHZXQgcGFyZW50cyBvZiB0eXBlIHdpdGggTkFNRS4KTkFN
RSBpcyBhIHN5bWJvbCByZXByZXNlbnRpbmcgYSB0eXBlLgpSZXR1cm4gYSBwb3NzaWJseSBl
bXB0eSBsaXN0IG9mIHR5cGVzLiIKICAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5k
LWNsYXNzIG5hbWUpKSkKCihkZWZzdWJzdCBjbC0tdHlwZS1jaGlsZHJlbiAobmFtZSkKICAi
R2V0IGNoaWxkcmVuIG9mIHRoZSB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCBy
ZXByZXNlbnRpbmcgYSB0eXBlLgpSZXR1cm4gYSBwb3NzaWJseSBlbXB0eSBsaXN0IG9mIHR5
cGVzLiIKICAoY2wtLWNsYXNzLWNoaWxkcmVuIChjbC0tZmluZC1jbGFzcyBuYW1lKSkpCgoo
ZGVmc3Vic3QgY2wtLXR5cGUtZGFnICh0eXBlcykKICAiUmV0dXJuIGEgREFHIGZyb20gdGhl
IGxpc3Qgb2YgVFlQRVMuIgogIChtYXBjYXIgIydjbC0tdHlwZS1wYXJlbnRzIHR5cGVzKSkK
Cjs7IEtlZXAgaXQgZm9yIG5vdywgZm9yIHRlc3RpbmcuCihkZWZ1biBjbC0tdHlwZS11bmRl
ZmluZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0aW9uIG9mIGNsLXR5cGUgd2l0aCBO
QU1FLgpOQU1FIGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBjbC10eXBl
LgpTaWduYWwgYW4gZXJyb3IgaWYgTkFNRSBoYXMgc3VidHlwZXMuIgogIChjbC1jaGVjay10
eXBlIG5hbWUgKHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAod2hlbi1sZXQqICgoY2hpbGRy
ZW4gKGFuZCAoY2wtLXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
IChjbC0tdHlwZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGls
ZHJlbjogJVMiIGNoaWxkcmVuKSkKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tdHlwZS1lcnJv
cikKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXByb3AgbmFtZSAn
Y2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRlbHEgbmFtZSBj
bC0tdHlwZS1saXN0KSkpCgooZGVmdW4gY2wtLXR5cGUtZGVmdHlwZSAobmFtZSBwYXJlbnRz
ICZvcHRpb25hbCBkb2NzdHJpbmcpCiAgOzsgRklYTUU6IFNob3VsZCB3ZSBhbHNvIHJlY2Vp
dmUgdGhlIGFyZ2xpc3Q/CiAgIkdlbmVyYWxpemUgY2wtdHlwZSB3aXRoIE5BTUUgZm9yIG1l
dGhvZCBkaXNwYXRjaGluZy4KUEFSRU5UUyBpcyBhIGxpc3Qgb2YgdHlwZXMgTkFNRSBpcyBh
IHN1YnR5cGUgb2YsIG9yIG5pbC4KRE9DU1RSSU5HIGlzIGFuIG9wdGlvbmFsIGRvY3VtZW50
YXRpb24gc3RyaW5nLiIKICAobGV0ICgodHlwZWxpc3QgY2wtLXR5cGUtbGlzdCkKICAgICAg
ICAob2xkcGxpc3QgKGNvcHktc2VxdWVuY2UgKHN5bWJvbC1wbGlzdCBuYW1lKSkpKQogICAg
KGNvbmRpdGlvbi1jYXNlIGVycgogICAgICAgIChsZXQqICgoY2xhc3MgKGNsLS1maW5kLWNs
YXNzIG5hbWUpKQogICAgICAgICAgICAgICAocmVjb3JkZWQgKG1lbXEgbmFtZSB0eXBlbGlz
dCkpKQogICAgICAgICAgKGlmIChudWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVs
bCByZWNvcmRlZCkKICAgICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVk
LCBidXQgZG9lc24ndCBleGlzdCIpKQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9y
ICJUeXBlIGV4aXN0cywgYnV0IG5vdCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3Ig
KGNsLXR5cGUtY2xhc3MtcCBjbGFzcykKICAgICAgICAgICAgICAgIDs7IEZJWE1FOiBXZSBo
YXZlIHNvbWUgdXNlcyBgY2wtZGVmdHlwZScgaW4gRW1hY3MgdGhhdAogICAgICAgICAgICAg
ICAgOzsgImNvbXBsZW1lbnQiIGFub3RoZXIgZGVjbGFyYXRpb24gb2YgdGhlIHNhbWUgdHlw
ZSwKICAgICAgICAgICAgICAgIDs7IHNvIG1heWJlIHdlIHNob3VsZCB0dXJuIHRoaXMgaW50
byBhIHdhcm5pbmcgKGFuZAogICAgICAgICAgICAgICAgOzsgbm90IG92ZXJ3cml0ZSB0aGUg
YGNsLS1maW5kLWNsYXNzJyBpbiB0aGF0IGNhc2UpPwogICAgICAgICAgICAgICAgKGVycm9y
ICJUeXBlIGluIGFub3RoZXIgY2xhc3M6ICVTIiAodHlwZS1vZiBjbGFzcykpKSkKICAgICAg
ICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9yIGZvciBOQU1FLgogICAgICAgICAgKHNl
dGYgKGNsLS1maW5kLWNsYXNzIG5hbWUpCiAgICAgICAgICAgICAgICAoY2wtLXR5cGUtY2xh
c3MtbWFrZSBuYW1lIGRvY3N0cmluZyBwYXJlbnRzKSkKICAgICAgICAgIChpZiByZWNvcmRl
ZAogICAgICAgICAgICAgIDs7IENsZWFyIGFueSBwcmV2aW91cyBlcnJvciBtYXJrLgogICAg
ICAgICAgICAgIChjbC1yZW1wcm9wIG5hbWUgJ2NsLS10eXBlLWVycm9yKQogICAgICAgICAg
ICA7OyBSZWNvcmQgbmV3IHR5cGUgdG8gaW5jbHVkZSBpdHMgZGVwZW5kZW5jeSBpbiB0aGUg
REFHLgogICAgICAgICAgICAocHVzaCBuYW1lIHR5cGVsaXN0KSkKICAgICAgICAgIDs7IGBj
bC10eXBlcy1vZicgaXRlcmF0ZXMgdGhyb3VnaCBhbGwga25vd24gdHlwZXMgdG8gY29sbGVj
dAogICAgICAgICAgOzsgYWxsIHRob3NlIGFuIG9iamVjdCBiZWxvbmdzIHRvLCBzb3J0ZWQg
ZnJvbSB0aGUgbW9zdAogICAgICAgICAgOzsgc3BlY2lmaWMgdHlwZSB0byB0aGUgbW9yZSBn
ZW5lcmFsIHR5cGUuICBTbywga2VlcCB0aGUKICAgICAgICAgIDs7IGdsb2JhbCBsaXN0IGlu
IHRoaXMgb3JkZXIuCiAgICAgICAgICA7OyBGSVhNRTogVGhpcyBnbG9iYWwgb3BlcmF0aW9u
IGlzIGEgYml0IHdvcnJpc29tZSwgYmVjYXVzZSBpdAogICAgICAgICAgOzsgc2NhbGVzIHBv
b3JseSB3aXRoIHRoZSBudW1iZXIgb2YgdHlwZXMuICBJIGd1ZXNzIGl0J3MgT0sKICAgICAg
ICAgIDs7IGZvciBub3cgYmVjYXVzZSBgY2wtZGVmdHlwZScgaXMgbm90IHZlcnkgcG9wdWxh
ciwgYnV0IGl0J2xsCiAgICAgICAgICA7OyBwcm9iYWJseSBuZWVkIHRvIGJlIHJlcGxhY2Vk
IGF0IHNvbWUgcG9pbnQuICBNYXliZSB3ZQogICAgICAgICAgOzsgc2hvdWxkIHNpbXBseSBy
ZXF1aXJlIHRoYXQgdGhlIHBhcmVudHMgYmUgZGVmaW5lZCBhbHJlYWR5LAogICAgICAgICAg
OzsgdGhlbiB3ZSBjYW4ganVzdCBgcHVzaCcgdGhlIG5ldyB0eXBlLCBrbm93aW5nIGl0J3Mg
aW4KICAgICAgICAgIDs7IHRvcG9sb2dpY2FsIG9yZGVyIGJ5IGNvbnN0cnVjdGlvbi4KICAg
ICAgICAgIChzZXRxIGNsLS10eXBlLWxpc3QKICAgICAgICAgICAgICAgIChtZXJnZS1vcmRl
cmVkLWxpc3RzCiAgICAgICAgICAgICAgICAgKGNsLS10eXBlLWRhZyB0eXBlbGlzdCkKICAg
ICAgICAgICAgICAgICAobGFtYmRhIChfKSAoZXJyb3IgIkludmFsaWQgZGVwZW5kZW5jeSBn
cmFwaCIpKSkpKQogICAgICAoZXJyb3IKICAgICAgIChzZXRmIChzeW1ib2wtcGxpc3QgbmFt
ZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAiRGVmaW5lICVTIGZhaWxlZDog
JXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJvci1tZXNzYWdlLXN0cmluZyBl
cnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gY2wtZGVmdHlwZTIgKG5hbWUg
YXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBhcyBhIG5ldyBkYXRhIHR5cGUu
ClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBgY2wtdHlwZWNhc2UnLCBgY2wt
Y2hlY2stdHlwZScsCmV0Yy4sIGFuZCBhcyBhcmd1bWVudCB0eXBlIGZvciBkaXNwYXRjaGlu
ZyBnZW5lcmljIGZ1bmN0aW9uIG1ldGhvZHMuCgpBUkdMSVNUIGlzIGEgQ29tbW9uIExpc3Ag
YXJndW1lbnQgbGlzdCBvZiB0aGUgc29ydCBhY2NlcHRlZCBieQpgY2wtZGVmbWFjcm8nLiAg
Qk9EWSBmb3JtcyBhcmUgZXZhbHVhdGVkIGFuZCBzaG91bGQgcmV0dXJuIGEgdHlwZQpzcGVj
aWZpZXIgdGhhdCBpcyBlcXVpdmFsZW50IHRvIHRoZSB0eXBlIChzZWUgdGhlIEluZm8gbm9k
ZSBgKGNsKSBUeXBlClByZWRpY2F0ZXMnIGluIHRoZSBHTlUgRW1hY3MgQ29tbW9uIExpc3Ag
RW11bGF0aW9uIG1hbnVhbCkuCgpJZiB0aGVyZSBpcyBhIGBkZWNsYXJlJyBmb3JtIGluIEJP
RFksIHRoZSBzcGVjIChwYXJlbnRzIFBBUkVOVFMpIGlzCnJlY29nbml6ZWQgdG8gc3BlY2lm
eSBhIGxpc3Qgb2YgdHlwZXMgTkFNRSBpcyBhIHN1YnR5cGUgb2YuICBGb3IKaW5zdGFuY2U6
CgogIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC1ieXRlICgmb3B0aW9uYWwgYml0cykKICAgIFwi
VW5zaWduZWQgaW50ZWdlci5cIgogICAgKGxpc3QgXFw9J2ludGVnZXIgMCAoaWYgKGVxIGJp
dHMgXFw9JyopIGJpdHMgKDEtIChhc2ggMSBiaXRzKSkpKSkKCiAgKGNsLWRlZnR5cGUyIHVu
c2lnbmVkLThiaXRzICgpCiAgICBcIlVuc2lnbmVkIDgtYml0cyBpbnRlZ2VyLlwiCiAgICAo
ZGVjbGFyZSAocGFyZW50cyB1bnNpZ25lZC1ieXRlKSkKICAgIFxcPScodW5zaWduZWQtYnl0
ZSA4KSkKClRoZSBsaXN0IG9mIFBBUkVOVFMgdHlwZXMgZGV0ZXJtaW5lcyB0aGUgb3JkZXIg
b2YgbWV0aG9kcyBpbnZvY2F0aW9uLAphbmQgbWlzc2luZyBQQVJFTlRTIG1heSBjYXVzZSBp
bmNvcnJlY3Qgb3JkZXJpbmcgb2YgbWV0aG9kcywgd2hpbGUKZXh0cmFuZW91cyBQQVJFTlRT
IG1heSBjYXVzZSB1c2Ugb2YgZXh0cmFuZW91cyBtZXRob2RzLgoKSWYgUEFSRU5UUyBpcyBu
b24tbmlsLCBBUkdMSVNUIG11c3QgYmUgbmlsLiIKICAoZGVjbGFyZSAoZGVidWcgY2wtZGVm
bWFjcm8pIChkb2Mtc3RyaW5nIDMpIChpbmRlbnQgMikpCiAgKHBjYXNlLWxldCoKICAgICAg
KChgKCxkZWNscyAuICxmb3JtcykgKG1hY3JvZXhwLXBhcnNlLWJvZHkgYm9keSkpCiAgICAg
ICAoZG9jc3RyaW5nIChpZiAoc3RyaW5ncCAoY2FyIGRlY2xzKSkKICAgICAgICAgICAgICAg
ICAgICAgIChjYXIgZGVjbHMpCiAgICAgICAgICAgICAgICAgICAgICAoY2FkciAoYXNzcSA6
ZG9jdW1lbnRhdGlvbiBkZWNscykpKSkKICAgICAgIChkZWNsYXJlcyAoYXNzcSAnZGVjbGFy
ZSBkZWNscykpCiAgICAgICAocGFyZW50LWRlY2wgKGFzc3EgJ3BhcmVudHMgKGNkciBkZWNs
YXJlcykpKQogICAgICAgKHBhcmVudHMgKGNkciBwYXJlbnQtZGVjbCkpKQogICAgKHdoZW4g
cGFyZW50LWRlY2wKICAgICAgOzsgIkNvbnN1bWUiIHRoZSBgcGFyZW50cycgZGVjbGFyYXRp
b24uCiAgICAgIChjbC1jYWxsZiAobGFtYmRhICh4KSAoZGVscSBwYXJlbnQtZGVjbCB4KSkg
KGNkciBkZWNsYXJlcykpCiAgICAgICh3aGVuIChlcXVhbCBkZWNsYXJlcyAnKGRlY2xhcmUp
KQogICAgICAgIChjbC1jYWxsZiAobGFtYmRhICh4KSAoZGVscSBkZWNsYXJlcyB4KSkgZGVj
bHMpKSkKICAgIChpZiAobWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgKGVycm9yICJUeXBl
IGluIHBhcmVudHM6ICVTIiBwYXJlbnRzKSkKICAgIChhbmQgcGFyZW50cyBhcmdsaXN0CiAg
ICAgICAgIChlcnJvciAiUGFyZW50cyBzcGVjaWZpZWQsIGJ1dCBhcmdsaXN0IG5vdCBlbXB0
eSIpKQogICAgYChldmFsLWFuZC1jb21waWxlIDs7Y2wtZXZhbC13aGVuIChjb21waWxlIGxv
YWQgZXZhbCkKICAgICAgIDs7IEZJWE1FOiBXaGVyZSBzaG91bGQgYGNsLS10eXBlLWRlZnR5
cGUnIGdvPyAgQ3VycmVudGx5LCBjb2RlCiAgICAgICA7OyB1c2luZyBgY2wtZGVmdHlwZScg
Y2FuIHVzZSAoZXZhbC13aGVuLWNvbXBpbGUgKHJlcXVpcmUKICAgICAgIDs7ICdjbC1saWIp
KSwgc28gYGNsLS10eXBlLWRlZnR5cGUnIG5lZWRzIHRvIGdvIGVpdGhlciB0bwogICAgICAg
OzsgYGNsLXByZWxvYWRlZC5lbCcgb3IgaXQgc2hvdWxkIGJlIGF1dG9sb2FkZWQgZXZlbiB3
aGVuCiAgICAgICA7OyBgY2wtbGliJyBpcyBub3QgbG9hZGVkLgogICAgICAgKGNsLS10eXBl
LWRlZnR5cGUgJyxuYW1lICcscGFyZW50cyAsZG9jc3RyaW5nKQogICAgICAgKGRlZmluZS1z
eW1ib2wtcHJvcCAnLG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcgogICAgICAgICAgICAgICAg
ICAgICAgICAgICAoY2wtZnVuY3Rpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgIChs
YW1iZGEgKCZjbC1kZWZzICgnKikgLEBhcmdsaXN0KQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAsQGRlY2xzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICxAZm9ybXMp
KSkpKSkKCjs7IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwnLgooZGVmdmFyIGNs
LS10eXBlLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkKICAiUmVjb3Jk
IGFuIHVuaXF1ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCihkZWZ1biBjbC0tdHlwZS1lcnJv
ciAodHlwZSBlcnJvcikKICAiTWFyayBUWVBFIGFzIGluLWVycm9yLCBhbmQgcmVwb3J0IHRo
ZSBwcm9kdWNlZCBFUlJPUiB2YWx1ZS4iCiAgKHB1dCB0eXBlICdjbC0tdHlwZS1lcnJvciBl
cnJvcikgOzsgTWFyayBUWVBFIGFzIGluLWVycm9yLgogIDs7IFRlbXBvcmFyaWx5IHJhaXNl
IHRoZSByZWN1cnNpb24gbGltaXQgdG8gYXZvaWQgYW5vdGhlciByZWN1cnNpb24KICA7OyBl
cnJvciB3aGlsZSByZXBvcnRpbmcgRVJST1IuCiAgKGxldCAoKG1heC1saXNwLWV2YWwtZGVw
dGggKCsgODAwIG1heC1saXNwLWV2YWwtZGVwdGgpKSkKICAgICh3YXJuICAiY2wtdHlwZXMt
b2YgJXMsICVzIiB0eXBlIChlcnJvci1tZXNzYWdlLXN0cmluZyBlcnJvcikpKQogIG5pbCkK
Cjs7IEZJWE1FOiBgY2wtdHlwZXMtb2YnIENQVSBjb3N0IGlzIHByb3BvcnRpb25hbCB0byB0
aGUgbnVtYmVyIG9mIHR5cGVzCjs7IGRlZmluZWQgd2l0aCBgY2wtZGVmdHlwZScsIHNvIHRo
ZSBtb3JlIHBvcHVsYXIgaXQgZ2V0cywgdGhlIHNsb3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5k
IG9mIGNvdXJzZSwgdGhlIGNvc3Qgb2YgZWFjaCB0eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRl
ZCwgc28gYSBzaW5nbGUgImV4cGVuc2l2ZSIgdHlwZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRv
d24KOzsgZnVydGhlci4KOzsKOzsgVGhlIHVzdWFsIGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxh
bWJkYSAoYXJnICZyZXN0IGFyZ3MpCjs7ICAgICAobGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlw
ZW9mIGFyZykgcHJlY29tcHV0ZWQtbWV0aG9kcy10YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7
OyAgICAgICAgICAgKGFwcGx5IGYgYXJnIGFyZ3MpCjs7ICAgICAgICAgOzsgU2xvdyBjYXNl
IHdoZW4gZW5jb3VudGVyaW5nIGEgbmV3IHR5cGUKOzsgICAgICAgICAuLi4pKSkKOzsKOzsg
d2hlcmUgb2Z0ZW4gdGhlIG1vc3QgZXhwZW5zaXZlIHBhcnQgaXMgYCZyZXN0JyAod2hpY2gg
aGFzIHRvCjs7IGFsbG9jYXRlIGEgbGlzdCBmb3IgdGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50
cyksCjs7Cjs7IFNvIHdlJ3JlIHRhbGtpbmcgYWJvdXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJl
c3QgKyBjbC10eXBlLW9mICsgZ2V0aGFzaCArIGlmICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1
bmN0aW9uIHRoYXQgbG9vcHMgb3ZlciBOIHR5cGVzLCBjYWxsaW5nIGBjbC10eXBlcCcgb24g
ZWFjaAo7OyBvbmUgb2YgdGhlbSAoYGNsLXR5cGVwJyBpdHNlbGYgYmVpbmcgYSByZWN1cnNp
dmUgZnVuY3Rpb24gdGhhdAo7OyBiYXNpY2FsbHkgaW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5n
dWFnZSkuICBUaGlzIGlzIGdvaW5nIHRvIHNsb3cKOzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNp
Z25pZmljYW50bHkgZm9yIHRob3NlIGdlbmVyaWMgZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBh
IG1ldGhvZCB0aGF0IGRpc3BhdGNoZXMgb24gYSB1c2VyIGRlZmluZWQgdHlwZSwgY29tcGFy
ZWQgdG8KOzsgdGhvc2UgdGhhdCBkb24ndC4KOzsKOzsgQSBwb3NzaWJsZSBmdXJ0aGVyIGlt
cHJvdmVtZW50Ogo7Owo7OyAtIGJhc2VkIG9uIHRoZSBQQVJFTlRTIGRlY2xhcmF0aW9uLCBj
cmVhdGUgYSBtYXAgZnJvbSBidWlsdGluLXR5cGUKOzsgICB0byB0aGUgc2V0IG9mIGNsLXR5
cGVzIHRoYXQgaGF2ZSB0aGF0IGJ1aWx0aW4tdHlwZSBhbW9uZyB0aGVpcgo7OyAgIHBhcmVu
dHMuICBUaGF0IHByZXN1bWVzIHNvbWUgUEFSRU5UUyBpbmNsdWRlIHNvbWUgYnVpbHRpbi10
eXBlcywKOzsgICBvYnZpb3VzbHkgb3RoZXJ3aXNlIHRoZSBtYXAgd2lsbCBiZSB0cml2aWFs
IHdpdGggYWxsIGNsLXR5cGVzCjs7ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBgdCcgImR1bW15
IHBhcmVudCIuICBbIFdlIGNvdWxkIGV2ZW4gZ28gY3JhenkKOzsgICBhbmQgdHJ5IGFuZCBn
dWVzcyBQQVJFTlRTIHdoZW4gbm90IHByb3ZpZGVkLCBieSBhbmFseXppbmcgdGhlCjs7ICAg
dHlwZSdzIGRlZmluaXRpb24uIF0KOzsKOzsgLSBpbiBgY2wtdHlwZXMtb2YnIHN0YXJ0IGJ5
IGNhbGxpbmcgYGNsLXR5cGUtb2YnLCB0aGVuIHVzZSB0aGUgbWFwCjs7ICAgdG8gZmluZCB3
aGljaCBjbC10eXBlcyBtYXkgbmVlZCB0byBiZSBjaGVja2VkLgo7OwooZGVmdW4gY2wtdHlw
ZXMtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4K
UmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRl
cmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMgdHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIK
ICAobGV0IChmb3VuZCkKICAgIDs7IEJ1aWxkIGEgbGlzdCBvZiBhbGwgdHlwZXMgT0JKRUNU
IGJlbG9uZ3MgdG8uCiAgICAoZG9saXN0ICh0eXBlIGNsLS10eXBlLWxpc3QpCiAgICAgIChh
bmQKICAgICAgIDs7IFNraXAgdHlwZSwgaWYgaXQgcHJldmlvdXNseSBwcm9kdWNlZCBhbiBl
cnJvci4KICAgICAgIChudWxsIChnZXQgdHlwZSAnY2wtLXR5cGUtZXJyb3IpKQogICAgICAg
OzsgU2tpcCB0eXBlIG5vdCBkZWZpbmVkIGJ5IGBjbC1kZWZ0eXBlJy4KICAgICAgIChjbC10
eXBlLWNsYXNzLXAgKGNsLS1maW5kLWNsYXNzIHR5cGUpKQogICAgICAgOzsgSWYgQkFSIGlz
IGRlY2xhcmVkIGFzIGEgcGFyZW50IG9mIEZPTyBhbmQgYGNsLXR5cGVzLW9mJyBoYXMKICAg
ICAgIDs7IGFscmVhZHkgZGVjaWRlZCB0aGF0IHRoZSB2YWx1ZSBpcyBvZiB0eXBlIEZPTywg
dGhlbiB3ZQogICAgICAgOzsgYWxyZWFkeSBrbm93IEJBUiB3aWxsIGJlIGluIHRoZSBvdXRw
dXQgYW55d2F5IGFuZCB0aGVyZSdzIG5vCiAgICAgICA7OyBwb2ludCB0ZXN0aW5nIEJBUi4g
IFNvLCBza2lwIHR5cGUgYWxyZWFkeSBzZWxlY3RlZCBhcyBwYXJlbnQKICAgICAgIDs7IG9m
IGFub3RoZXIgdHlwZSwgYXNzdW1pbmcgdGhhdCwgbW9zdCBvZiB0aGUgdGltZSwgYGFzc3En
CiAgICAgICA7OyB3aWxsIGJlIGZhc3RlciB0aGFuIGBjbC10eXBlcCcuCiAgICAgICAobnVs
bCAoYXNzcSB0eXBlIGZvdW5kKSkKICAgICAgIDs7IElmIE9CSkVDVCBpcyBvZiB0eXBlLCBh
ZGQgdHlwZSB0byB0aGUgbWF0Y2hpbmcgbGlzdC4KICAgICAgIChjb25kaXRpb24tY2FzZS11
bmxlc3MtZGVidWcgZQogICAgICAgICAgIChjbC10eXBlcCBvYmplY3QgdHlwZSkKICAgICAg
ICAgKGVycm9yIChjbC0tdHlwZS1lcnJvciB0eXBlIGUpKSkKICAgICAgIChwdXNoIHR5cGUg
Zm91bmQpKSkKICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUgb2YgdGhlIGxpc3Qgb2Yg
dHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8sCiAgICA7OyB3aGljaCBpcyBhbHNvIHRoZSBsaXN0
IG9mIHNwZWNpZmllcnMgZm9yIE9CSkVDVC4KICAgICh3aXRoLW1lbW9pemF0aW9uIChnZXRo
YXNoIGZvdW5kIGNsLS10eXBlLXVuaXF1ZSkKICAgICAgOzsgQ29tcHV0ZSBhIERBRyBmcm9t
IHRoZSBjb2xsZWN0ZWQgbWF0Y2hpbmcgdHlwZXMuCiAgICAgIChsZXQgKGRhZykKICAgICAg
ICAoZG9saXN0ICh0eXBlIGZvdW5kKQogICAgICAgICAgKGxldCAoKHBsIChjbC0tdHlwZS1w
YXJlbnRzIHR5cGUpKSkKICAgICAgICAgICAgKHdoaWxlIHBsCiAgICAgICAgICAgICAgKHB1
c2ggcGwgZGFnKQogICAgICAgICAgICAgIChzZXRxIHBsIChjZHIgcGwpKSkpKQogICAgICAg
IDs7IENvbXB1dGUgYW4gb3JkZXJlZCBsaXN0IG9mIHR5cGVzIGZyb20gdGhlIERBRy4KICAg
ICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAobnJldmVyc2UgKGNvbnMgKGNs
LS10eXBlLXBhcmVudHMgKGNsLXR5cGUtb2Ygb2JqZWN0KSkKICAgICAgICAgICAgICAgICAg
ICAgICAgIGRhZykpKSkpKSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGNsLWdlbmVy
aWMtZGVmaW5lLWdlbmVyYWxpemVyIGNsLS10eXBlLWdlbmVyYWxpemVyCiAgMjAgOzsgInR5
cGVvZiIgPCAiY2wtdHlwZXMtb2YiIDwgImhlYWQiIHByaW9yaXR5CiAgKGxhbWJkYSAob2Jq
ICZyZXN0IF8pIGAoY2wtdHlwZXMtb2YgLG9iaikpCiAgKGxhbWJkYSAodGFnICZyZXN0IF8p
IChpZiAoY29uc3AgdGFnKSB0YWcpKSkKCihjbC1kZWZtZXRob2QgY2wtZ2VuZXJpYy1nZW5l
cmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1vZiIgKHR5cGUpCiAgIlN1cHBvcnQgZm9yIGRp
c3BhdGNoIG9uIGNsLXR5cGVzLiIKICAoaWYgKGNsLS10eXBlLXAgdHlwZSkKICAgICAgKGxp
c3QgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoK
KHByb3ZpZGUgJ2NsLXR5cGVzKQoKOzs7IGNsLXR5cGVzLmVsIGVuZHMgaGVyZQo=
--------------wX7ISlduev3upoIOjvky26gv--
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Apr 2025 14:50:06 +0000
Resent-Message-ID: <handler.77725.B77725.17459381733504 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.17459381733504
(code B ref 77725); Tue, 29 Apr 2025 14:50:06 +0000
Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 14:49:33 +0000
Received: from localhost ([127.0.0.1]:57373 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9mH3-0000tl-RF
for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 10:49:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16544)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u9mH1-0000tF-Je
for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 10:49:28 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8C1D980899;
Tue, 29 Apr 2025 10:49:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745938160;
bh=mkTbuINwmSDkztYGst3Z0eR4jzswi/QaNLR2LIh6nAA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=RJ8Bt/NPxVtXpKNvoUzExJbZOd3m6BEj3vgSQyFnY9BtOJfssUfPOtF4riliRI+o1
GkdL9q6qtHthdEQvFJWQS3F34ECB1Z3wpWJ7+lVPg/4CW5fyC3wdqOHy3Y3hqPt9iw
OvqOciOtyqZoUJzxf/lP4JUngu9uDTWCWwKCBEk1RL3J1xFbUj+Twk3Z/DWGo00qYw
29OL3MdimSXtS/dCn+xUy5xfzK6BLH98abWb2nsDKIZ28IXOqepcprpPlOHk8O+2D4
/EMTuKfm5mVAgnGWuiEv7bspgUQqQum4jV7pcinWpFys7qO4JdpARU96yOxrvzTh54
xMF9yYN62rIkQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A50F78034C;
Tue, 29 Apr 2025 10:49:20 -0400 (EDT)
Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7687112041B;
Tue, 29 Apr 2025 10:49:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
Message-ID: <jwvjz73ujru.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
<jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
<bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
Date: Tue, 29 Apr 2025 10:49:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.060 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> ;; FIXME: This global operation is a bit worrisome, because it
> ;; scales poorly with the number of types. I guess it's OK
> ;; for now because `cl-deftype' is not very popular, but it'll
> ;; probably need to be replaced at some point. Maybe we
> ;; should simply require that the parents be defined already,
> ;; then we can just `push' the new type, knowing it's in
> ;; topological order by construction.
>
> It's not clear to me how "simply require that the parents be defined
> already", makes the new type "in topological order by construction".
If they're already defined, it means they're already in the list, so if
you add the new type at the head of the list you know this "child" comes
before all its parents in the list. If the list is constructed only by
making such additions where we make sure the parents are already there,
then the property is valid over the whole list.
Note, there's no magic: we should push the responsibility of topological
sorting onto the programmers (who now have to define their types in
topological order).
> Also, as all this is done only at type (re)definition, which should
> not happen so often, I am curious to know why you think "this global
> operation is a bit worrisome"?
The algorithmic complexity of merge-ordered-list is O(N=B2), in the number
of types IIRC, so while it may seem fine with 10 types, it could take
more than a minute given enough type declarations.
> In `cl-types-of', I liked your idea to avoid calls to
> `cl--type-parents' and `merge-ordered-list' before we do the
> `gethash'. I've gone a bit further in this direction (hopefully not
> too far!) by doing all the type list computation just before creating
> a new entry in the hash table. There's a slight overhead to determine
> the types of objects not yet processed, but determining the types of
> similar objects should be faster, which should be the most common case
> (or at least the one to favor) when using types to dispatch methods.
+1
I notice that the `(null (assq type found))` is now ineffective, tho.
Maybe it's OK and we should just remove it.
> WDYT
Why all the `defsubst`? Have you measured a noticeable speed difference
by using them? I have a hard time seeing how that could happen.
All 3 `defsubst` in your patch are for function which contain
a non-trivial loop, so I'd expect the overhead of a function call to be
negligible.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: David Ponce <da_vid@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Apr 2025 15:51:06 +0000
Resent-Message-ID: <handler.77725.B77725.1745941802326 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.1745941802326
(code B ref 77725); Tue, 29 Apr 2025 15:51:06 +0000
Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 15:50:02 +0000
Received: from localhost ([127.0.0.1]:58462 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9nDd-00004u-3Z
for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 11:50:02 -0400
Received: from smtp-76.smtpout.orange.fr ([80.12.242.76]:50417
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u9nDZ-0008WI-Ok
for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 11:49:59 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 9nDTuHv0NSxyX9nDWuhXzX; Tue, 29 Apr 2025 17:49:55 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745941796;
bh=8q+eSYvP4FOPoqGRD8u48wrN885/HYs218/kEQDjChw=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=VKzQeEH50Y/z5Xb4rAq64EhIAalBWoslLTVk/HEsl5ifH0IqAq0kwvXmHLWR19chh
VdO7sIzsShTuFWI8TkIIzNppIuyfv25L4R4gceddyqIMeH6ZWM4ST9dtqFS1XwXJem
DhJ4DaRADYO+mr/f/7ff/+AjCH1qJob7ihKqR6OWANZV+7WOwWxEQD93d2PgSYSM/u
8e1pD0BBMDAKOHEBtop9SXl9f7TLuyhuQatXfc+H49d+y85DIG85vzdx0JRBuljAj0
uvPc1YjQ9gJmvmRTp6Ex7ig6GcLcYnMyAnb0Q4g04Mo3p6AVBoCWegHVzqf6Tqf6N5
h3QeeoW1g//2A==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Tue, 29 Apr 2025 17:49:56 +0200
X-ME-IP: 90.112.40.65
Message-ID: <e03aadc4-5a8f-464b-b79d-f9408bf460ff@HIDDEN>
Date: Tue, 29 Apr 2025 17:49:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
<jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
<bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
<jwvjz73ujru.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvjz73ujru.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-29 16:49, Stefan Monnier wrote:
>> ;; FIXME: This global operation is a bit worrisome, because it
>> ;; scales poorly with the number of types. I guess it's OK
>> ;; for now because `cl-deftype' is not very popular, but it'll
>> ;; probably need to be replaced at some point. Maybe we
>> ;; should simply require that the parents be defined already,
>> ;; then we can just `push' the new type, knowing it's in
>> ;; topological order by construction.
>>
>> It's not clear to me how "simply require that the parents be defined
>> already", makes the new type "in topological order by construction".
>
> If they're already defined, it means they're already in the list, so if
> you add the new type at the head of the list you know this "child" comes
> before all its parents in the list. If the list is constructed only by
> making such additions where we make sure the parents are already there,
> then the property is valid over the whole list.
>
> Note, there's no magic: we should push the responsibility of topological
> sorting onto the programmers (who now have to define their types in
> topological order).
Of course, it makes much sense. If I am not wrong, the constructor of the
class `cl-type-class' already ensures that parent types must be defined
before their "child" types (i.e. already added to the `cl--type-list' for
types defined with `cl-deftype"). So it should work to simply push a new
type at the beginning of the list. And, when a type is redefined, move it
at the beginning of the list?
>> Also, as all this is done only at type (re)definition, which should
>> not happen so often, I am curious to know why you think "this global
>> operation is a bit worrisome"?
>
> The algorithmic complexity of merge-ordered-list is O(N²), in the number
> of types IIRC, so while it may seem fine with 10 types, it could take
> more than a minute given enough type declarations.
I understand now, thanks!
>
>> In `cl-types-of', I liked your idea to avoid calls to
>> `cl--type-parents' and `merge-ordered-list' before we do the
>> `gethash'. I've gone a bit further in this direction (hopefully not
>> too far!) by doing all the type list computation just before creating
>> a new entry in the hash table. There's a slight overhead to determine
>> the types of objects not yet processed, but determining the types of
>> similar objects should be faster, which should be the most common case
>> (or at least the one to favor) when using types to dispatch methods.
>
> +1
>
> I notice that the `(null (assq type found))` is now ineffective, tho.
> Maybe it's OK and we should just remove it.
Good catch :-) I think it's OK to just remove this test.
> Why all the `defsubst`? Have you measured a noticeable speed difference
> by using them? I have a hard time seeing how that could happen.
> All 3 `defsubst` in your patch are for function which contain
> a non-trivial loop, so I'd expect the overhead of a function call to be
> negligible.
Sorry, that's a bit paranoid of me, as I've heard many times that function
calls are inefficient in ELisp. You're certainly right: in this case, the
overhead of a function call should be negligible. I'll replace those
"defsubst" with "defun".
David
X-Loop: help-debbugs@HIDDEN
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Apr 2025 16:34:02 +0000
Resent-Message-ID: <handler.77725.B77725.174594441821511 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77725
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: David Ponce <da_vid@HIDDEN>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 77725-submit <at> debbugs.gnu.org id=B77725.174594441821511
(code B ref 77725); Tue, 29 Apr 2025 16:34:02 +0000
Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 16:33:38 +0000
Received: from localhost ([127.0.0.1]:59239 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9ntn-0005aB-03
for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 12:33:38 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13927)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u9ntk-0005Zk-Ci
for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 12:33:32 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 842C910006B;
Tue, 29 Apr 2025 12:33:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745944405;
bh=SLa37Nfh0KjiephG7vjwffCZMRD/D1MKDVLJ8GLuEek=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=FSvKfI+i9q2gSIc8gbebh5Z9VHHUREDWHUUJBZ66rZ1yctwhDS8TcZlZPvAFSChjw
fSlmvoOiyBrYaahEwpmzf8slRaxGvHy8AQZW9cYcZk7wVYGaU5T9v+2vq/EclJauvG
jubimB3Io0d4H8UKXLnGL1MgRZBUq5K9Tt1LRefFvmIi2mUUgNEu64K8/EhgJJWPZ+
fqpdH/+mBlXIbJ9KmiPWIiRXc53lldKqGL5KCbXb2vEUmhHIV884Vh4ZSFO6EYNQ7A
P1y2A1Oj/aed1Z4p1uKA4WIBJls8o8OXesSIVsJCto/W8zgXrQTNp+rfR+uWnHy8uD
eq33mJJsi4U/w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D2631100029;
Tue, 29 Apr 2025 12:33:25 -0400 (EDT)
Received: from asado (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 975A5120199;
Tue, 29 Apr 2025 12:33:16 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <e03aadc4-5a8f-464b-b79d-f9408bf460ff@HIDDEN>
Message-ID: <jwvo6wfymbe.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
<jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
<bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
<jwvjz73ujru.fsf-monnier+emacs@HIDDEN>
<e03aadc4-5a8f-464b-b79d-f9408bf460ff@HIDDEN>
Date: Tue, 29 Apr 2025 12:33:06 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.292 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Of course, it makes much sense. If I am not wrong, the constructor of the
> class `cl-type-class' already ensures that parent types must be defined
> before their "child" types (i.e. already added to the `cl--type-list' for
> types defined with `cl-deftype").
I think so, yes.
> So it should work to simply push a new type at the beginning of the
> list.
Yup.
> And, when a type is redefined, move it at the beginning of
> the list?
Redefinition is more complicated, because child types may be in the
list, so moving the type to the head can be incorrect. The "cheap"
solution is to leave the list unchanged (and hope the redefinition
doesn't change the hierarchy too much).
Side note: Redefinitions introduce other problems as well because the
class object's `parents` slot contains references to `cl--class`
objects, so after a redefinition via (setf (cl--find-class FOO) ...),
the children's `parents` slots point to the old class object.
That's a problem that affects all types and that we don't really try to
solve currently.
> Sorry, that's a bit paranoid of me, as I've heard many times that function
> calls are inefficient in ELisp.
FWIW, calls from bytecode to bytecode have been improved noticeable by
Mattias (can't remember if that was for Emacs-29 or Emacs-30), so it's
not as bad as it used to be.
> You're certainly right: in this case, the overhead of a function call
> should be negligible. I'll replace those "defsubst" with "defun".
It's good to be mindful of costs, but it's also important to remember
that the majority of the code is actually not performance sensitive at
all (by which I mean that small constant factors, like what you get from
inlining, don't matter).
Stefan
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.