From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Oct 2023 18:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 66615@debbugs.gnu.org Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier X-Debbugs-Original-To: Received: via spool by submit@debbugs.gnu.org id=B.169765240825052 (code B ref -1); Wed, 18 Oct 2023 18:07:02 +0000 Received: (at submit) by debbugs.gnu.org; 18 Oct 2023 18:06:48 +0000 Received: from localhost ([127.0.0.1]:34636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtAwR-0006Vz-WB for submit@debbugs.gnu.org; Wed, 18 Oct 2023 14:06:48 -0400 Received: from lists.gnu.org ([2001:470:142::17]:54450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtAwP-0006Vk-5l for submit@debbugs.gnu.org; Wed, 18 Oct 2023 14:06:46 -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 ) id 1qtAvt-0002NZ-Ks for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 14:06:13 -0400 Received: from mail-vi1eur05on20619.outbound.protection.outlook.com ([2a01:111:f400:7d00::619] helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtAvq-0007JI-S1 for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 14:06:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZTD4W0TqtXG1cGqqQQTd0+7awcA2mNXAMtxsVxJwVbg/38Up5K5l2fn17o2VA3ayL5zNlOvtdEnTTse+V6dxpkh6yEyWbxO8azjsLoVrUPITXmV5U+n5O/Ih1+dKtrYgfL0y1bMrX5stssqHlcmNo4uvB0w6Di/RHeX81xcZ80Ny4Ywp/3jPekBDatAPD5EXf410gn9yZSbHyQWcpHSvh5oocLxueR2Q26aieCJbSolDSFsiEzRG8QxMJ7z8nlJVfbOmkLDhbMnZ4Nz/lJff4OHLE/IbAdxB1WCKNEo/MSWiaYdsOmG1GKwOJPSzcnYAIzIxSWIigjWitbipQaX6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IAohIgSzDgEVrKyNBAdg0CF6jkrV/Sb7/lPH77DiBl4=; b=JoqtCN5cpszFKw3YQIttHCXwHWAoNx9RIgJO2RRIU7ppmLp7bmJdUWzhpGTM5KvBf1ICvbVGpMJ/2pH2np61P7XjS8GZrZ/T4qYx6mJheMdWxXte+SasYQlojiYQWmmIWPs20QCCj+M9tcTmNp48FJP3eiBhMuWlZshG198A/FNHuVt5RYICHH3+2uFtVSBQOb/UnWNWKQyQk6RS5kJmie6iv4J+ha/O2ajdSs2tn+xW3TiGdskhMj3+DlUHGClzGe8J0nUtR+z8n0Kz+Ejg2bVJVNJwJF3F8X4XrHCH8bENAgkYTlrF6OEwyfSf7us55Y01eac8fgp9h/m2HbDwLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 40.67.248.234) smtp.rcpttodomain=iro.umontreal.ca smtp.mailfrom=gnu.org; dmarc=fail (p=none sp=none pct=100) action=none header.from=gnu.org; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IAohIgSzDgEVrKyNBAdg0CF6jkrV/Sb7/lPH77DiBl4=; b=llSO+8J2vcX0ePQR/drG6gyDgb1Zlg8gSoA4DjL+y5ip4wRwT7eIPm02hVVVLiQGMQpnuIun+aUOFk0zOhrYyRSYTuOiwgWeLIi73RfY/CYOko3RA25jcFgzLnyz7t9htOvMD+HgLofLmJpthWOiuZGQFONfGmXZlSPcmh7OqD4= Received: from AS8P251CA0014.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:2f2::13) by DU0PR08MB8905.eurprd08.prod.outlook.com (2603:10a6:10:47d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.36; Wed, 18 Oct 2023 18:01:04 +0000 Received: from AM7EUR03FT028.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:2f2:cafe::c0) by AS8P251CA0014.outlook.office365.com (2603:10a6:20b:2f2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.24 via Frontend Transport; Wed, 18 Oct 2023 18:01:04 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 40.67.248.234) smtp.mailfrom=gnu.org; dkim=none (message not signed) header.d=none;dmarc=fail action=none header.from=gnu.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning gnu.org discourages use of 40.67.248.234 as permitted sender) Received: from nebula.arm.com (40.67.248.234) by AM7EUR03FT028.mail.protection.outlook.com (100.127.140.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6907.24 via Frontend Transport; Wed, 18 Oct 2023 18:01:03 +0000 Received: from AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) by AZ-NEU-EX04.Arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 18 Oct 2023 18:01:02 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 18 Oct 2023 18:01:02 +0000 Received: from e124257 (10.34.101.64) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Wed, 18 Oct 2023 18:01:02 +0000 From: Andrea Corallo Date: Wed, 18 Oct 2023 13:59:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM7EUR03FT028:EE_|DU0PR08MB8905:EE_ X-MS-Office365-Filtering-Correlation-Id: ff4063f8-1a33-42ff-7456-08dbd0043186 NoDisclaimer: true X-MS-Exchange-SenderADCheck: 2 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OvpXi4dkTRy5bVheRInUqF2g/GigErL/VxI5AF7kcaByyWq3rmRI2HBLAmZN4nJb82OVCj+CagfJX3UO9tNssXF6xc8xIrfA2DLZM6hyLC9kT/mVsTdlWSXHLpY34tbsz9dQ0QS79nYWTMB1XbbQuc6N5w7PssKOBmix5IFfsPthOLxj/KylEkhqVQobvgqRj9QgdFA8LkIahGObT1eUrUAFVR7+tAtWtHiWK4ncw54nl1AeIzxyGmoOgS+0J4ek1JLBN1Wg9BvL//3wqfc2brSTq0PVC/osEcEy7bBP1QH7q7ap+u6ClUgHdr6X3QzjLD/GKv02C760NSYVx7GGB9owVB1ioXKbMDfVCnzMbTBnNA3AcR37kLJfs9fwNSfGnd7/tYWv5GCNDjprJnJPT566EEl7vOqqZixUHCwXJXKMzaVbs4lbTDBCIwqfziQ2cIpgveA//wmOkOKuzdBoYkOd76BdbdamqPyIDyytuYpCmnLVnK43CesFrMN6Gp1pIFLVddIC8b+Kgu/O6XNaD02Hg6oLzcFWAo8umMjEFdpr2SuK6HIoXxMWQC+lQiZd4syWut2c0sAdTdmGDtDzitg4laUPybif6l3kB6MCYqE5CZfE0GkveRh1UrLMCn1QT7qSVeRqb9j+XzrckZVFjnBgw7bA0qtjMnHmejfJvsfX69jzzR6UJIxA9r5ZjDpoXWZhNLtGucguufvIvbpar2OEITPPFFnK9XQ3x0RsbXxPhtGUSocAATyT3/AiGiFpvmAYHWWYtyFK5tPuwLc3aQ== X-Forefront-Antispam-Report: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230031)(4636009)(376002)(39860400002)(346002)(136003)(396003)(230922051799003)(64100799003)(61400799006)(451199024)(82310400011)(48200799006)(40470700004)(46966006)(40460700003)(70206006)(316002)(70586007)(6636002)(47076005)(54906003)(4326008)(35950700001)(8676002)(8936002)(82740400003)(498600001)(53546011)(356005)(83380400001)(336012)(6666004)(26005)(40480700001)(2906002)(86362001)(5660300002)(41300700001)(81166007)(296002)(6916009); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2023 18:01:03.1773 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff4063f8-1a33-42ff-7456-08dbd0043186 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[40.67.248.234]; Helo=[nebula.arm.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8905 Received-SPF: pass client-ip=2a01:111:f400:7d00::619; envelope-from=bounces+SRS=splFO=GA@arm.com; helo=EUR05-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) 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: Hello all, while performing some development I noticed that 'number-or-marker' is mentioned as a type in 'cl--typeof-types'. Unfortunatelly its entry is missing in 'cl-deftype-satisfies' (see cl-macs.el:3469). Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=bounces%2Bsrs%3Dsplfo%3Dga%40arm.com; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 TO_EQ_FM_DOM_SPF_FAIL To domain == From domain and external SPF failed X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello all, while performing some development I noticed that 'number-or-marker' is mentioned as a type in 'cl--typeof-types'. Unfortunatelly its entry is missing in 'cl-deftype-satisfies' (see cl-macs.el:3469). My question is, why do we consider 'number-or-marker' in the first place a type if we support the or syntax in `cl-typep' like (cl-typep 3 '(or marker number)) ? I'd like to fix this inconsistency in order to progress with my development, originally I worked out the attached patch but I now suspect that (unless there's a specific reason) we should just remove 'number-or-marker' as a type entirely instead. WDYT? Thanks Andrea PS also I think we have a similar issue/question with 'integer-or-marker'. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename="0001-Add-two-missing-number-or-marker-entries-to-the-cl-m.patch" >From 05d85f19e51c15df8824df8e8608784ec79b37cf Mon Sep 17 00:00:00 2001 From: Andrea Corallo Date: Wed, 18 Oct 2023 16:10:08 +0200 Subject: [PATCH] Add two missing 'number-or-marker' entries to the cl machinery. Assuming 'number-or-marker' is a type (as present multiple times in cl--typeof-types) adding some missing entries for coherency. * lisp/emacs-lisp/cl-preloaded.el (cl--typeof-types): Add 'number-or-marker' as supertype of 'number' in the 'float' branch. * lisp/emacs-lisp/cl-macs.el (cl-deftype-satisfies): Add 'number-or-marker'. * test/lisp/emacs-lisp/comp-cstr-tests.el (comp-cstr-typespec-tests-alist): Update test. * test/src/comp-tests.el (comp-tests-type-spec-tests): Update two testes. --- lisp/emacs-lisp/cl-macs.el | 3 ++- lisp/emacs-lisp/cl-preloaded.el | 4 ++-- test/lisp/emacs-lisp/comp-cstr-tests.el | 2 +- test/src/comp-tests.el | 4 ++-- 4 files changed, 7 insertions(+), 6 deletions(-) diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el index 8025a64f1bf..722d561b9f4 100644 --- a/lisp/emacs-lisp/cl-macs.el +++ b/lisp/emacs-lisp/cl-macs.el @@ -3502,7 +3502,8 @@ cl--macroexp-fboundp (symbol . symbolp) (vector . vectorp) (window . windowp) - ;; FIXME: Do we really want to consider this a type? + ;; FIXME: Do we really want to consider these types? + (number-or-marker . number-or-marker-p) (integer-or-marker . integer-or-marker-p) )) (put type 'cl-deftype-satisfies pred)) diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 676326980aa..96e288db7d5 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -58,8 +58,8 @@ cl--typeof-types ;; Markers aren't `numberp', yet they are accepted wherever integers are ;; accepted, pretty much. (marker number-or-marker atom) - (overlay atom) (float number atom) (window-configuration atom) - (process atom) (window atom) + (overlay atom) (float number number-or-marker atom) + (window-configuration atom) (process atom) (window atom) ;; FIXME: We'd want to put `function' here, but that's only true ;; for those `subr's which aren't special forms! (subr atom) diff --git a/test/lisp/emacs-lisp/comp-cstr-tests.el b/test/lisp/emacs-lisp/comp-cstr-tests.el index a4f282fcfef..d2f552af6fa 100644 --- a/test/lisp/emacs-lisp/comp-cstr-tests.el +++ b/test/lisp/emacs-lisp/comp-cstr-tests.el @@ -191,7 +191,7 @@ ;; 74 ((and boolean (or number marker)) . nil) ;; 75 - ((and atom (or number marker)) . (or marker number)) + ((and atom (or number marker)) . number-or-marker) ;; 76 ((and symbol (or number marker)) . nil) ;; 77 diff --git a/test/src/comp-tests.el b/test/src/comp-tests.el index 4444ab61219..31871bb2eec 100644 --- a/test/src/comp-tests.el +++ b/test/src/comp-tests.el @@ -977,7 +977,7 @@ comp-tests-check-ret-type-spec (if (= x y) x 'foo)) - '(or (member foo) marker number)) + '(or (member foo) marker-or-number)) ;; 14 ((defun comp-tests-ret-type-spec-f (x) @@ -1117,7 +1117,7 @@ comp-tests-check-ret-type-spec ((defun comp-tests-ret-type-spec-f (x) (when (> x 1.0) x)) - '(or null marker number)) + '(or null number-or-marker)) ;; 36 ((defun comp-tests-ret-type-spec-f (x y) -- 2.25.1 --=-=-=-- From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Oct 2023 18:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 66615@debbugs.gnu.org, mattias.engdegard@gmail.com X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Received: via spool by submit@debbugs.gnu.org id=B.169765399728370 (code B ref -1); Wed, 18 Oct 2023 18:34:01 +0000 Received: (at submit) by debbugs.gnu.org; 18 Oct 2023 18:33:17 +0000 Received: from localhost ([127.0.0.1]:34663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtBM4-0007NW-S2 for submit@debbugs.gnu.org; Wed, 18 Oct 2023 14:33:17 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtBM2-0007NI-8l for submit@debbugs.gnu.org; Wed, 18 Oct 2023 14:33:15 -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 ) id 1qtBLW-0002mV-Ca for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 14:32:42 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtBLU-0003v2-DA; Wed, 18 Oct 2023 14:32:42 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3FA77805D6; Wed, 18 Oct 2023 14:32:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1697653956; bh=M8WUdh7xI1vjM4PJf7B9b1LteE3rVayn0NxPCd4qu9w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZPXa35niTjpgts1NpQ1APD/1WFPQlu2pyfbcnKlt2+bFP3TZ2CVQ/AlB5sEGTQUe4 ewCtsOXbuSZmryA2NXStKg/yJ3ahzVnsbkXrux81/sBqObRMYQ1/vBI3Doz0qAje13 sMpjfLoNnzajp4k4qlkyqtnNMf6i7QMDgkY25+oWjUsxA9FIwE1K1lMyNrk1W0b39u Ykc+CBW/vCZAPQawgXobq+6hDtTbxNPPugc87OQ5ISgqMXP/7JMio3wHt2BAV0DbJt 2fHfcuURXiNk9G9H3x2cH8+7fJiB8zmt4wCmDC9WjSOH1Cg1rq34VGIDMG+kYKaeYm RiqjAc3herMpA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AD727804BC; Wed, 18 Oct 2023 14:32:36 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9DC1812038A; Wed, 18 Oct 2023 14:32:36 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Andrea Corallo's message of "Wed, 18 Oct 2023 13:59:21 -0400") Message-ID: References: Date: Wed, 18 Oct 2023 14:30: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.073 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: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > My question is, why do we consider 'number-or-marker' in the first place > a type if we support the or syntax in `cl-typep' like > (cl-typep 3 '(or marker number)) ? I'm not sure I can give a good answer in general, but I can tell you some reasons that explain some of what we see: - There is a `number-or-marker-p` primitive and `cl-typep` doesn't know how to use it for `(or number marker)`. - method specializers (currently) can't be `(or number marker)` but can be `number-or-marker`. > I'd like to fix this inconsistency in order to progress with my > development, originally I worked out the attached patch but I now > suspect that (unless there's a specific reason) we should just remove > 'number-or-marker' as a type entirely instead. I'd lean towards keeping it :-) > PS also I think we have a similar issue/question with > 'integer-or-marker'. Yup. Stefan From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Oct 2023 08:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.16977058405859 (code B ref 66615); Thu, 19 Oct 2023 08:58:02 +0000 Received: (at 66615) by debbugs.gnu.org; 19 Oct 2023 08:57:20 +0000 Received: from localhost ([127.0.0.1]:35805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtOqG-0001WR-2P for submit@debbugs.gnu.org; Thu, 19 Oct 2023 04:57:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtOqB-0001W7-Nf for 66615@debbugs.gnu.org; Thu, 19 Oct 2023 04:57:18 -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 ) id 1qtOpf-0002SC-K6; Thu, 19 Oct 2023 04:56:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=DAjtVWtFiAhB9mCbFVRG+0wFjrIMDDvg4dviX60dITg=; b=hEVx4kTzWDK9bBi4f8C5 TQo2qCmix02XFxg6UtVP9WfegiJi/GducjMSRzIO41Fiz7Bwd+Kr8krFkiombwIv7O0tPxJ664eLM vUr7tZCyeE5frvgev+/hT6toXs8AA3rNKCb1cZTA7bz62AK6v/CvsmWfmv5QCPzFEtfx1dUwsczv1 qOf87MSOze65ugsWUk8Ro67wreCzsYSN6IL+oJHSTzgoxbtLV8uA/T7fKw7Udj/sgdP2Xlui8t3GW 9tWgZ/MySOoHs2iTAehM2zd80wT1rE9RgkVepvjdSy8M7ZGM5RkH2ksn2aiPUUY15FriM9c6DYN+i DJzi1zrvduMNNQ==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qtOpf-0008GW-Dt; Thu, 19 Oct 2023 04:56:43 -0400 From: Andrea Corallo In-Reply-To: (Stefan Monnier's message of "Wed, 18 Oct 2023 14:30:38 -0400") References: Date: Thu, 19 Oct 2023 04:56:42 -0400 Message-ID: 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-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [re-replaying as for some reason our responses didn't reach the list] Stefan Monnier writes: >> My question is, why do we consider 'number-or-marker' in the first place >> a type if we support the or syntax in `cl-typep' like >> (cl-typep 3 '(or marker number)) ? > > I'm not sure I can give a good answer in general, but I can tell you > some reasons that explain some of what we see: > > - There is a `number-or-marker-p` primitive and `cl-typep` doesn't know > how to use it for `(or number marker)`. Well we could just remove 'number-or-marker-p' =F0=9F=98=83 > - method specializers (currently) can't be `(or number marker)` but can be > `number-or-marker`. Okay this is more difficult to fix... :/ >> I'd like to fix this inconsistency in order to progress with my >> development, originally I worked out the attached patch but I now >> suspect that (unless there's a specific reason) we should just remove >> 'number-or-marker' as a type entirely instead. > > I'd lean towards keeping it :-) I see your point, actually my main drive is to make the situation more coherent so I'm unblocked in the first place, just the method specializer functionality is a blocker for removing 'number-or-marker'. I think adding 'number-or-marker' where missing is probably the best solution for now. Thanks Andrea From unknown Fri Jun 20 07:23:40 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Andrea Corallo Subject: bug#66615: closed (Re: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery) Message-ID: References: X-Gnu-PR-Message: they-closed 66615 X-Gnu-PR-Package: emacs Reply-To: 66615@debbugs.gnu.org Date: Thu, 19 Oct 2023 12:04:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1697717042-28642-1" This is a multi-part message in MIME format... ------------=_1697717042-28642-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl-= machinery which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 66615@debbugs.gnu.org. --=20 66615: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66615 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1697717042-28642-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 66615-done) by debbugs.gnu.org; 19 Oct 2023 12:03:20 +0000 Received: from localhost ([127.0.0.1]:36007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtRkF-0007Qy-RU for submit@debbugs.gnu.org; Thu, 19 Oct 2023 08:03:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtRkD-0007Qg-Ay for 66615-done@debbugs.gnu.org; Thu, 19 Oct 2023 08:03:18 -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 ) id 1qtRjh-0002Ly-8y; Thu, 19 Oct 2023 08:02:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=WjWMR3V/8qoMmkeN0VctELnXiO4S4VfN/rDt+Hq/R9g=; b=HfDP0Cwd6A7aTRZr5F/S 1dPsD8TKT5Q0hGgViK84wuVS8S4v0YqBKJ4ihoqI9ungy5AosmQ5Qn4yzgp/zt1gfPduDY8pauh30 CKrLvlH0YNNPxBnrWRcnnfNKT1PZDw1DfRWNxUfeRDojbKypJ/8gAfSg3AW2kDtpSODMw9Wh2azKK ttEIHnTvWK/y8wAjtlTwJPMopMCWrLj3Pz/oEa+HwBIwojAGOZ6UMu1174HOEHn/eFORS85RpFrSe IVjMTJpsYi3YprCzlDJefwT+9aLCKL7N0mqxQ8DQin0kaXkx5ODDe28dCmzkfDP4Wq8HF4GtgImY1 i2BoVgxbTfREhA==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qtRje-0002oF-CO; Thu, 19 Oct 2023 08:02:44 -0400 From: Andrea Corallo To: Stefan Monnier Subject: Re: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery In-Reply-To: (Andrea Corallo's message of "Thu, 19 Oct 2023 04:56:42 -0400") References: Date: Thu, 19 Oct 2023 08:02:42 -0400 Message-ID: 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-Score: -2.3 (--) X-Debbugs-Envelope-To: 66615-done Cc: 66615-done@debbugs.gnu.org, Mattias =?utf-8?Q?Engdeg=C3=A5rd?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Andrea Corallo writes: > [re-replaying as for some reason our responses didn't reach the list] > > Stefan Monnier writes: > >>> My question is, why do we consider 'number-or-marker' in the first place >>> a type if we support the or syntax in `cl-typep' like >>> (cl-typep 3 '(or marker number)) ? >> >> I'm not sure I can give a good answer in general, but I can tell you >> some reasons that explain some of what we see: >> >> - There is a `number-or-marker-p` primitive and `cl-typep` doesn't know >> how to use it for `(or number marker)`. > > Well we could just remove 'number-or-marker-p' =F0=9F=98=83 > >> - method specializers (currently) can't be `(or number marker)` but can = be >> `number-or-marker`. > > Okay this is more difficult to fix... :/ > >>> I'd like to fix this inconsistency in order to progress with my >>> development, originally I worked out the attached patch but I now >>> suspect that (unless there's a specific reason) we should just remove >>> 'number-or-marker' as a type entirely instead. >> >> I'd lean towards keeping it :-) > > I see your point, actually my main drive is to make the situation more > coherent so I'm unblocked in the first place, just the method > specializer functionality is a blocker for removing 'number-or-marker'. > > I think adding 'number-or-marker' where missing is probably the best > solution for now. Okay with a567faf4c2b I added 'number-or-marker' where it was missing. Closing this, happy to reopen if necessary. Thanks! Andrea ------------=_1697717042-28642-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 18 Oct 2023 18:06:48 +0000 Received: from localhost ([127.0.0.1]:34636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtAwR-0006Vz-WB for submit@debbugs.gnu.org; Wed, 18 Oct 2023 14:06:48 -0400 Received: from lists.gnu.org ([2001:470:142::17]:54450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtAwP-0006Vk-5l for submit@debbugs.gnu.org; Wed, 18 Oct 2023 14:06:46 -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 ) id 1qtAvt-0002NZ-Ks for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 14:06:13 -0400 Received: from mail-vi1eur05on20619.outbound.protection.outlook.com ([2a01:111:f400:7d00::619] helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtAvq-0007JI-S1 for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 14:06:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZTD4W0TqtXG1cGqqQQTd0+7awcA2mNXAMtxsVxJwVbg/38Up5K5l2fn17o2VA3ayL5zNlOvtdEnTTse+V6dxpkh6yEyWbxO8azjsLoVrUPITXmV5U+n5O/Ih1+dKtrYgfL0y1bMrX5stssqHlcmNo4uvB0w6Di/RHeX81xcZ80Ny4Ywp/3jPekBDatAPD5EXf410gn9yZSbHyQWcpHSvh5oocLxueR2Q26aieCJbSolDSFsiEzRG8QxMJ7z8nlJVfbOmkLDhbMnZ4Nz/lJff4OHLE/IbAdxB1WCKNEo/MSWiaYdsOmG1GKwOJPSzcnYAIzIxSWIigjWitbipQaX6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IAohIgSzDgEVrKyNBAdg0CF6jkrV/Sb7/lPH77DiBl4=; b=JoqtCN5cpszFKw3YQIttHCXwHWAoNx9RIgJO2RRIU7ppmLp7bmJdUWzhpGTM5KvBf1ICvbVGpMJ/2pH2np61P7XjS8GZrZ/T4qYx6mJheMdWxXte+SasYQlojiYQWmmIWPs20QCCj+M9tcTmNp48FJP3eiBhMuWlZshG198A/FNHuVt5RYICHH3+2uFtVSBQOb/UnWNWKQyQk6RS5kJmie6iv4J+ha/O2ajdSs2tn+xW3TiGdskhMj3+DlUHGClzGe8J0nUtR+z8n0Kz+Ejg2bVJVNJwJF3F8X4XrHCH8bENAgkYTlrF6OEwyfSf7us55Y01eac8fgp9h/m2HbDwLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 40.67.248.234) smtp.rcpttodomain=iro.umontreal.ca smtp.mailfrom=gnu.org; dmarc=fail (p=none sp=none pct=100) action=none header.from=gnu.org; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IAohIgSzDgEVrKyNBAdg0CF6jkrV/Sb7/lPH77DiBl4=; b=llSO+8J2vcX0ePQR/drG6gyDgb1Zlg8gSoA4DjL+y5ip4wRwT7eIPm02hVVVLiQGMQpnuIun+aUOFk0zOhrYyRSYTuOiwgWeLIi73RfY/CYOko3RA25jcFgzLnyz7t9htOvMD+HgLofLmJpthWOiuZGQFONfGmXZlSPcmh7OqD4= Received: from AS8P251CA0014.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:2f2::13) by DU0PR08MB8905.eurprd08.prod.outlook.com (2603:10a6:10:47d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.36; Wed, 18 Oct 2023 18:01:04 +0000 Received: from AM7EUR03FT028.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:2f2:cafe::c0) by AS8P251CA0014.outlook.office365.com (2603:10a6:20b:2f2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.24 via Frontend Transport; Wed, 18 Oct 2023 18:01:04 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 40.67.248.234) smtp.mailfrom=gnu.org; dkim=none (message not signed) header.d=none;dmarc=fail action=none header.from=gnu.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning gnu.org discourages use of 40.67.248.234 as permitted sender) Received: from nebula.arm.com (40.67.248.234) by AM7EUR03FT028.mail.protection.outlook.com (100.127.140.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6907.24 via Frontend Transport; Wed, 18 Oct 2023 18:01:03 +0000 Received: from AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) by AZ-NEU-EX04.Arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 18 Oct 2023 18:01:02 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 18 Oct 2023 18:01:02 +0000 Received: from e124257 (10.34.101.64) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Wed, 18 Oct 2023 18:01:02 +0000 From: Andrea Corallo To: Subject: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Date: Wed, 18 Oct 2023 13:59:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM7EUR03FT028:EE_|DU0PR08MB8905:EE_ X-MS-Office365-Filtering-Correlation-Id: ff4063f8-1a33-42ff-7456-08dbd0043186 NoDisclaimer: true X-MS-Exchange-SenderADCheck: 2 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OvpXi4dkTRy5bVheRInUqF2g/GigErL/VxI5AF7kcaByyWq3rmRI2HBLAmZN4nJb82OVCj+CagfJX3UO9tNssXF6xc8xIrfA2DLZM6hyLC9kT/mVsTdlWSXHLpY34tbsz9dQ0QS79nYWTMB1XbbQuc6N5w7PssKOBmix5IFfsPthOLxj/KylEkhqVQobvgqRj9QgdFA8LkIahGObT1eUrUAFVR7+tAtWtHiWK4ncw54nl1AeIzxyGmoOgS+0J4ek1JLBN1Wg9BvL//3wqfc2brSTq0PVC/osEcEy7bBP1QH7q7ap+u6ClUgHdr6X3QzjLD/GKv02C760NSYVx7GGB9owVB1ioXKbMDfVCnzMbTBnNA3AcR37kLJfs9fwNSfGnd7/tYWv5GCNDjprJnJPT566EEl7vOqqZixUHCwXJXKMzaVbs4lbTDBCIwqfziQ2cIpgveA//wmOkOKuzdBoYkOd76BdbdamqPyIDyytuYpCmnLVnK43CesFrMN6Gp1pIFLVddIC8b+Kgu/O6XNaD02Hg6oLzcFWAo8umMjEFdpr2SuK6HIoXxMWQC+lQiZd4syWut2c0sAdTdmGDtDzitg4laUPybif6l3kB6MCYqE5CZfE0GkveRh1UrLMCn1QT7qSVeRqb9j+XzrckZVFjnBgw7bA0qtjMnHmejfJvsfX69jzzR6UJIxA9r5ZjDpoXWZhNLtGucguufvIvbpar2OEITPPFFnK9XQ3x0RsbXxPhtGUSocAATyT3/AiGiFpvmAYHWWYtyFK5tPuwLc3aQ== X-Forefront-Antispam-Report: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230031)(4636009)(376002)(39860400002)(346002)(136003)(396003)(230922051799003)(64100799003)(61400799006)(451199024)(82310400011)(48200799006)(40470700004)(46966006)(40460700003)(70206006)(316002)(70586007)(6636002)(47076005)(54906003)(4326008)(35950700001)(8676002)(8936002)(82740400003)(498600001)(53546011)(356005)(83380400001)(336012)(6666004)(26005)(40480700001)(2906002)(86362001)(5660300002)(41300700001)(81166007)(296002)(6916009); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2023 18:01:03.1773 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff4063f8-1a33-42ff-7456-08dbd0043186 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[40.67.248.234]; Helo=[nebula.arm.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8905 Received-SPF: pass client-ip=2a01:111:f400:7d00::619; envelope-from=bounces+SRS=splFO=GA@arm.com; helo=EUR05-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) 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: Hello all, while performing some development I noticed that 'number-or-marker' is mentioned as a type in 'cl--typeof-types'. Unfortunatelly its entry is missing in 'cl-deftype-satisfies' (see cl-macs.el:3469). Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=bounces%2Bsrs%3Dsplfo%3Dga%40arm.com; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 TO_EQ_FM_DOM_SPF_FAIL To domain == From domain and external SPF failed X-Debbugs-Envelope-To: submit Cc: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello all, while performing some development I noticed that 'number-or-marker' is mentioned as a type in 'cl--typeof-types'. Unfortunatelly its entry is missing in 'cl-deftype-satisfies' (see cl-macs.el:3469). My question is, why do we consider 'number-or-marker' in the first place a type if we support the or syntax in `cl-typep' like (cl-typep 3 '(or marker number)) ? I'd like to fix this inconsistency in order to progress with my development, originally I worked out the attached patch but I now suspect that (unless there's a specific reason) we should just remove 'number-or-marker' as a type entirely instead. WDYT? Thanks Andrea PS also I think we have a similar issue/question with 'integer-or-marker'. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename="0001-Add-two-missing-number-or-marker-entries-to-the-cl-m.patch" >From 05d85f19e51c15df8824df8e8608784ec79b37cf Mon Sep 17 00:00:00 2001 From: Andrea Corallo Date: Wed, 18 Oct 2023 16:10:08 +0200 Subject: [PATCH] Add two missing 'number-or-marker' entries to the cl machinery. Assuming 'number-or-marker' is a type (as present multiple times in cl--typeof-types) adding some missing entries for coherency. * lisp/emacs-lisp/cl-preloaded.el (cl--typeof-types): Add 'number-or-marker' as supertype of 'number' in the 'float' branch. * lisp/emacs-lisp/cl-macs.el (cl-deftype-satisfies): Add 'number-or-marker'. * test/lisp/emacs-lisp/comp-cstr-tests.el (comp-cstr-typespec-tests-alist): Update test. * test/src/comp-tests.el (comp-tests-type-spec-tests): Update two testes. --- lisp/emacs-lisp/cl-macs.el | 3 ++- lisp/emacs-lisp/cl-preloaded.el | 4 ++-- test/lisp/emacs-lisp/comp-cstr-tests.el | 2 +- test/src/comp-tests.el | 4 ++-- 4 files changed, 7 insertions(+), 6 deletions(-) diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el index 8025a64f1bf..722d561b9f4 100644 --- a/lisp/emacs-lisp/cl-macs.el +++ b/lisp/emacs-lisp/cl-macs.el @@ -3502,7 +3502,8 @@ cl--macroexp-fboundp (symbol . symbolp) (vector . vectorp) (window . windowp) - ;; FIXME: Do we really want to consider this a type? + ;; FIXME: Do we really want to consider these types? + (number-or-marker . number-or-marker-p) (integer-or-marker . integer-or-marker-p) )) (put type 'cl-deftype-satisfies pred)) diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 676326980aa..96e288db7d5 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -58,8 +58,8 @@ cl--typeof-types ;; Markers aren't `numberp', yet they are accepted wherever integers are ;; accepted, pretty much. (marker number-or-marker atom) - (overlay atom) (float number atom) (window-configuration atom) - (process atom) (window atom) + (overlay atom) (float number number-or-marker atom) + (window-configuration atom) (process atom) (window atom) ;; FIXME: We'd want to put `function' here, but that's only true ;; for those `subr's which aren't special forms! (subr atom) diff --git a/test/lisp/emacs-lisp/comp-cstr-tests.el b/test/lisp/emacs-lisp/comp-cstr-tests.el index a4f282fcfef..d2f552af6fa 100644 --- a/test/lisp/emacs-lisp/comp-cstr-tests.el +++ b/test/lisp/emacs-lisp/comp-cstr-tests.el @@ -191,7 +191,7 @@ ;; 74 ((and boolean (or number marker)) . nil) ;; 75 - ((and atom (or number marker)) . (or marker number)) + ((and atom (or number marker)) . number-or-marker) ;; 76 ((and symbol (or number marker)) . nil) ;; 77 diff --git a/test/src/comp-tests.el b/test/src/comp-tests.el index 4444ab61219..31871bb2eec 100644 --- a/test/src/comp-tests.el +++ b/test/src/comp-tests.el @@ -977,7 +977,7 @@ comp-tests-check-ret-type-spec (if (= x y) x 'foo)) - '(or (member foo) marker number)) + '(or (member foo) marker-or-number)) ;; 14 ((defun comp-tests-ret-type-spec-f (x) @@ -1117,7 +1117,7 @@ comp-tests-check-ret-type-spec ((defun comp-tests-ret-type-spec-f (x) (when (> x 1.0) x)) - '(or null marker number)) + '(or null number-or-marker)) ;; 36 ((defun comp-tests-ret-type-spec-f (x y) -- 2.25.1 --=-=-=-- ------------=_1697717042-28642-1-- From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Oct 2023 14:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.16977253692059 (code B ref 66615); Thu, 19 Oct 2023 14:23:02 +0000 Received: (at 66615) by debbugs.gnu.org; 19 Oct 2023 14:22:49 +0000 Received: from localhost ([127.0.0.1]:37390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtTvE-0000X9-R3 for submit@debbugs.gnu.org; Thu, 19 Oct 2023 10:22:49 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47019) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtTvB-0000Ws-Ou for 66615@debbugs.gnu.org; Thu, 19 Oct 2023 10:22:48 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 861EF4428A0; Thu, 19 Oct 2023 10:22:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1697725332; bh=M6uoOdMUh3fxGctpliqsXDfYfNCVFYSqU/aRlbFUM5k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YTRpFdK53NQPLYsGZGLXpIje9bUla2FZzuHb8qNFwtkwej5w8AVVMYHH29/oGertz Q6Am2PBKQZvvJTcb5Lf4LicitkKsAhwdOAwX1EGeY/jF2M+pfZno8+Le7eFiE5WHJF krfYkPacYbUPz2OBcl64kW3stEbo6Gcl2NITEn9Cf6xwDXsKxTAd3Vk3BA7JjsvfLi qtAgXCUC+8Fm+4goe88wrEs2Y99ObcR/iHm2EGIU3/2KbAQS9wv/SFi1WwEgVk0zYg 1ENuSSho0idP2uuPog0L8Wr+bw1reyX7UphXJhZfomZL1AB3NYQvDjdXwCyLUdXvvF l+5/DeHSr53cg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0257544289C; Thu, 19 Oct 2023 10:22:12 -0400 (EDT) Received: from pastel (unknown [45.72.216.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D08BD1202CB; Thu, 19 Oct 2023 10:22:11 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Andrea Corallo's message of "Thu, 19 Oct 2023 08:02:42 -0400") Message-ID: References: Date: Thu, 19 Oct 2023 10:22:10 -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.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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> - There is a `number-or-marker-p` primitive and `cl-typep` doesn't know >>> how to use it for `(or number marker)`. >> Well we could just remove 'number-or-marker-p' =F0=9F=98=83 Indeed, or we could teach `cl-typep` how to make use of it. >> I see your point, actually my main drive is to make the situation more >> coherent so I'm unblocked in the first place, just the method >> specializer functionality is a blocker for removing 'number-or-marker'. That's what I had understood, and indeed there were some loose ends there. > Okay with a567faf4c2b I added 'number-or-marker' where it was missing. Thanks. I also added corresponding `integer-or-marker`. Stefan From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Oct 2023 21:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169775070019569 (code B ref 66615); Thu, 19 Oct 2023 21:25:02 +0000 Received: (at 66615) by debbugs.gnu.org; 19 Oct 2023 21:25:00 +0000 Received: from localhost ([127.0.0.1]:38013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtaVn-00055Y-Q8 for submit@debbugs.gnu.org; Thu, 19 Oct 2023 17:25:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtaVk-00055I-N2 for 66615@debbugs.gnu.org; Thu, 19 Oct 2023 17:24:58 -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 ) id 1qtaVD-0001yz-Ve; Thu, 19 Oct 2023 17:24:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=Yk/ftiwvveEW3jW6VCFNAhAhzUpMJ+KNpgBohsPkBSg=; b=e4YAEyEiA9hchjjS5ruu +tZwD4NzFxqlNw5kPOwT1169WlZoeu8jifvXXHWUcIDtIccK47fuJVtmoYLpnckwiqyzvafY4OaTn lO/kdkypZadETpzgFGcc8FKebMe8Uf0TcnUEWEQx+LdYh38AVwdHzXlJXVmp9l559BvugBLxAChHW 3nuFzmhFiZ1HGfzgOcvM4AvQNzTYLlVc7dlee2Vt11Awsp9yNnt7E6pEnmxlp0TxhmBz5S/MYilW2 nE33rZxOygXXMjy/0SA2I96b8Oa5LNJMlNI04cXSRjTmi8qs0yL9fRW4sglnx0STV1rFfnXCEVboh uztyWLJ8EfWKQA==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qtaVD-0003uK-OT; Thu, 19 Oct 2023 17:24:23 -0400 From: Andrea Corallo In-Reply-To: (Stefan Monnier's message of "Thu, 19 Oct 2023 10:22:10 -0400") References: Date: Thu, 19 Oct 2023 17:24:23 -0400 Message-ID: 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-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >>>> - There is a `number-or-marker-p` primitive and `cl-typep` doesn't know >>>> how to use it for `(or number marker)`. >>> Well we could just remove 'number-or-marker-p' =F0=9F=98=83 > > Indeed, or we could teach `cl-typep` how to make use of it. > >>> I see your point, actually my main drive is to make the situation more >>> coherent so I'm unblocked in the first place, just the method >>> specializer functionality is a blocker for removing 'number-or-marker'. > > That's what I had understood, and indeed there were some loose ends there. > >> Okay with a567faf4c2b I added 'number-or-marker' where it was missing. > > Thanks. I also added corresponding `integer-or-marker`. Hi Stefan thanks, I've to question now the following entry introduced in `cl--typeof-types' for correctness: (integer number integer-or-marker number-or-marker atom) The doc says : Each element has the form (TYPE . SUPERTYPES) where TYPE is one of the symbols returned by =E2=80=98type-of=E2=80=99, and SUPERTYPES is the li= st of its supertypes from the most specific to least specific. And indeed not every 'number' is an 'integer-or-marker'. I suspect that's the reason why this commit introduces few failures in the native-comp testsuite. At this point of the night I'm not sure if and how 'integer-or-marker' can be added correctly to this representation. Best Regards Andrea From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Oct 2023 22:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169775491828139 (code B ref 66615); Thu, 19 Oct 2023 22:36:01 +0000 Received: (at 66615) by debbugs.gnu.org; 19 Oct 2023 22:35:18 +0000 Received: from localhost ([127.0.0.1]:38054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtbbq-0007Jn-Ay for submit@debbugs.gnu.org; Thu, 19 Oct 2023 18:35:18 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtbbm-0007JY-Hk for 66615@debbugs.gnu.org; Thu, 19 Oct 2023 18:35:16 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C280100151; Thu, 19 Oct 2023 18:34:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1697754880; bh=09lpd+LWcRzlOnxMxj4CnJ/+l5IfnnZHSm8NDUwonsI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Lq8hnpxf85FdAdQtfsbTO3A0B25ZzaXOKjZHYVRnGsu6XA9Cdmc/9FZvuIG4riiK7 veYBa8o8yaDZBqXd2sBvNeDhJ2m9u1YPkxkeJDUYt4FzKyQV8xTGhEccybf2aGStRm p9ofuEsfyYZOeEYzsYf83y8JavZKb0lt3DX6DnB7Igwnmdbh+9lFy+gDKZ39zbgp+1 vL9aIjRd8SUF36IdtUBi2ns6H2t2bTCxFHtQIq52cFFqnkGj90pptBttdCwmY4pxVl yRl+G2kmlrC181yorn9Z5sZWaC4LQddn29OUlbm5J5Xl0aG2pU/vNgj21vIgPFDtUZ H4oRT+xMbi/yQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E661A1000A3; Thu, 19 Oct 2023 18:34:40 -0400 (EDT) Received: from pastel (unknown [45.72.216.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BE7831202CB; Thu, 19 Oct 2023 18:34:40 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Andrea Corallo's message of "Thu, 19 Oct 2023 17:24:23 -0400") Message-ID: References: Date: Thu, 19 Oct 2023 18:34:39 -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.154 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I've to question now the following entry introduced in > `cl--typeof-types' for correctness: > > (integer number integer-or-marker number-or-marker atom) > > The doc says : > Each element has the form (TYPE . SUPERTYPES) where TYPE is one of > the symbols returned by =E2=80=98type-of=E2=80=99, and SUPERTYPES is the = list of its > supertypes from the most specific to least specific. > > And indeed not every 'number' is an 'integer-or-marker'. The subtype relation doesn't derive from a tree but a DAG so the SUPERTYPES represents *a* linearization of the parents but just because `number` appears before `integer-or-marker` doesn't mean that it's a subtype of it. It just means I judged that it should be considered "more specific". The same effect is in play for: (null symbol list sequence atom) where clearly `symbol` is a subtype of neither `list` nor `sequence`. > I suspect that's the reason why this commit introduces few failures in > the native-comp testsuite. If you need to know the list of supertypes of `number`, we could add that info explicitly, or you could "guess" it as the intersection of all the types that appear after `number` in `cl--typeof-types`: (integer number integer-or-marker number-or-marker atom) [...] (float number number-or-marker atom) [...] i.e. the intersection of (integer-or-marker number-or-marker atom) and (number-or-marker atom). Stefan From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2023 09:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169779278830736 (code B ref 66615); Fri, 20 Oct 2023 09:07:02 +0000 Received: (at 66615) by debbugs.gnu.org; 20 Oct 2023 09:06:28 +0000 Received: from localhost ([127.0.0.1]:38629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtlSe-0007ze-B1 for submit@debbugs.gnu.org; Fri, 20 Oct 2023 05:06:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtlSZ-0007zO-GG for 66615@debbugs.gnu.org; Fri, 20 Oct 2023 05:06:26 -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 ) id 1qtlS1-00051G-JC; Fri, 20 Oct 2023 05:05:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=l/uu301k8zj1MzkRlghzLKaZnfmHXK+9iTkzQyMOPpI=; b=nOIIF7rWWiBatQpl78E/ UtBT8PRUSbxez/t34cNEZXmLQrii1DCpoxi7WC4M1K7Yn/WyJkkc1satxH4bviv9ydBRJhA1sU6JT GGaB2KOx4SCwI3rkJBsqt0IYKR8a9cIH35qvJOXfRdfia7xsNZ3UsA/Fo4ILb5VzcLXubHmrrNcFk SXX9BUJGDmQnMsGsw1nIpfD/PcS8Pbd+YeAnJZ1tO7PDudcvgLZ9IUpCf5eHK8NZTLsy0dBl20myY H3M0/Jt98p8iu00gfnA5nTxoojf8P++y129ukMZm/QqY3xHZZYGk0FenQ97s1CZsNMSyAB9noHJVg 647ZC2YpbG8C4Q==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qtlRz-00080S-Au; Fri, 20 Oct 2023 05:05:49 -0400 From: Andrea Corallo In-Reply-To: (Stefan Monnier's message of "Thu, 19 Oct 2023 18:34:39 -0400") References: Date: Fri, 20 Oct 2023 05:05:47 -0400 Message-ID: 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-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >> I've to question now the following entry introduced in >> `cl--typeof-types' for correctness: >> >> (integer number integer-or-marker number-or-marker atom) >> >> The doc says : >> Each element has the form (TYPE . SUPERTYPES) where TYPE is one of >> the symbols returned by =E2=80=98type-of=E2=80=99, and SUPERTYPES is the= list of its >> supertypes from the most specific to least specific. >> >> And indeed not every 'number' is an 'integer-or-marker'. > > The subtype relation doesn't derive from a tree but a DAG so the > SUPERTYPES represents *a* linearization of the parents but just because > `number` appears before `integer-or-marker` doesn't mean that it's > a subtype of it. It just means I judged that it should be considered > "more specific". > > The same effect is in play for: > > (null symbol list sequence atom) > > where clearly `symbol` is a subtype of neither `list` nor `sequence`. Hi Stefan, I understand now thanks, the trouble is that the hierarchy is not a tree but a DAG and these are just single linearizations. I think we should improve this part of the docstring as doesn't sound complete to me. Also shouldn't we add (null boolean symbol atom) to cover this other path as well? >> I suspect that's the reason why this commit introduces few failures in >> the native-comp testsuite. > > If you need to know the list of supertypes of `number`, we could add > that info explicitly, or you could "guess" it as the intersection of all > the types that appear after `number` in `cl--typeof-types`: > > (integer number integer-or-marker number-or-marker atom) > [...] > (float number number-or-marker atom) > [...] > > i.e. the intersection of (integer-or-marker number-or-marker atom) > and (number-or-marker atom). I think I understand how to do it, OTOH might be better to have the hierarchy made explicit somewhere? Still have to think to make an opinion on this. Thanks Andrea From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2023 13:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169780954220463 (code B ref 66615); Fri, 20 Oct 2023 13:46:02 +0000 Received: (at 66615) by debbugs.gnu.org; 20 Oct 2023 13:45:42 +0000 Received: from localhost ([127.0.0.1]:38973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtpor-0005Jx-Pj for submit@debbugs.gnu.org; Fri, 20 Oct 2023 09:45:42 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtpop-0005Je-0z for 66615@debbugs.gnu.org; Fri, 20 Oct 2023 09:45:40 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4E15D4429D3; Fri, 20 Oct 2023 09:45:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1697809504; bh=dVhZPHW6KiUzraW7rr4TaBrxcm0gCBAXe6fr1GyJptU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VOd9MUDner3A9anxkNYgPJy+nIlpAuOooiF9Jv2kKBRc8YnQ4zFV3wH6J/+qZS8oG 4QBW9AlzPNboyTdGTmZnrq/v/mUDXItQRFuuo7MBnJhdAHP1RtvxcVfU+uhou4zK9h DNnnvAtdNZ/oGWULSmnSQmogOL5lMtf6iYufetgu33Jx0rutV81Y9CEobn9w7zB5sn lCXCJezF4p52/GhAUMNo/CesaYAb78rbF7PeI+KmWBNf+aYsyfQcjPMPIFli90htyz yKygazLNkhmYe4fhFAknh8ASGHRjwNtccsGcPWmR50oBca8T+ISVyXxFzkjTMUobFf PY32GduTvyk/w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5B97A4429CF; Fri, 20 Oct 2023 09:45:04 -0400 (EDT) Received: from pastel (unknown [45.72.216.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1205D1202A1; Fri, 20 Oct 2023 09:45:04 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Andrea Corallo's message of "Fri, 20 Oct 2023 05:05:47 -0400") Message-ID: References: Date: Fri, 20 Oct 2023 09:45:03 -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.006 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I think we should improve this part of the docstring as doesn't sound > complete to me. Suggestions welcome. > Also shouldn't we add (null boolean symbol atom) to cover this other > path as well? You mean add `boolean` in there? No objection on my side. Stefan From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2023 15:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.16978165703771 (code B ref 66615); Fri, 20 Oct 2023 15:43:01 +0000 Received: (at 66615) by debbugs.gnu.org; 20 Oct 2023 15:42:50 +0000 Received: from localhost ([127.0.0.1]:41243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtreD-0000yl-UK for submit@debbugs.gnu.org; Fri, 20 Oct 2023 11:42:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtre9-0000yV-2U for 66615@debbugs.gnu.org; Fri, 20 Oct 2023 11:42:48 -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 ) id 1qtrda-00031m-9p; Fri, 20 Oct 2023 11:42:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=hD8zWnHK+j6gOy/ZtfIAo1xbZOJebxhWzNjLAeARPyM=; b=IEZTSAPcGNOdK4L9mZWE VD9xTh9bCIr+R8rOS7j8l6Ai7mZOA2r6wEOXqmJ5BbAOxQWQ3+TA8pF12sE9MnynMI7CdmvxJakWG Sw894UkxkBGo8NahQ3Ls1pqpsZXumYTB3Y58i9oxHIopKN3ItgIK/J9WTI9bq1/Qtr7qAwEii+p+u 73ynjpllqEDlXav7HZPbRSSeJKfypws6M3A5H0HrThtTnuCjcFtmqSRmuPViKDiWnLd4aK3Ij4hee gajFJZ0p+j/kAb+ofGzKbEs96oeQqbsk3rU3z4sczpDAS2F9r4YoOGmR3+95mv9mVTFPIQASKrutg 1C+vst45agHMEg==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qtrda-0003qz-3W; Fri, 20 Oct 2023 11:42:10 -0400 From: Andrea Corallo In-Reply-To: (Stefan Monnier's message of "Fri, 20 Oct 2023 09:45:03 -0400") References: Date: Fri, 20 Oct 2023 11:42:10 -0400 Message-ID: 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-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >> I think we should improve this part of the docstring as doesn't sound >> complete to me. > > Suggestions welcome. > >> Also shouldn't we add (null boolean symbol atom) to cover this other >> path as well? > > You mean add `boolean` in there? > No objection on my side. Sorry I'm just trying to understand, I'm happy to write patches but I need to understand first. IIUC for this sub part of the hierarchy we have: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=BA t =E2=97= =84=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 =E2=94=82 =E2=94=82 atom =E2=94=82 =E2=96=B2 =E2=94=82 =E2=94=82 sequence symbol =E2=96=B2 =E2=96=B2 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 list =E2=97=84=E2=94=80=E2=94=80=E2=94=80=E2=94=90 boolean =E2=96=B2 =E2=94=82 =E2=96=B2 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=A4 =E2=94=82 =E2=94=82 cons null now I'm fine with having say (getting the relevant parts from `cl--typeof-types' and adding boolean in the null's one as you suggested): (null boolean symbol list sequence atom) (cons list sequence) (symbol atom) as entries, but how are these sufficient to reconstruct this hierarchy? (null boolean symbol list sequence atom) is not a linearization of the DAG, is just (TYPE . SUPERTYPES) where SUPERTYPES have no specific order. Am I wrong? How can current code (say dispatch on builtin types) work if we can't infer if 'sequence' is higher or lower in the hierarchy respect to 'list'? I think the original idea (as expressed by the doc) of having "the list of its supertypes from the most specific to least specific" works for reconstructing the DAG if we have one entry per path to the top, say: (null boolean symbol atom) (null list sequence) (cons list sequence) But I might be easyly missing many things here. Thanks! (A confused) Andrea From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2023 20:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169783516821795 (code B ref 66615); Fri, 20 Oct 2023 20:53:01 +0000 Received: (at 66615) by debbugs.gnu.org; 20 Oct 2023 20:52:48 +0000 Received: from localhost ([127.0.0.1]:41729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtwU7-0005fP-CT for submit@debbugs.gnu.org; Fri, 20 Oct 2023 16:52:47 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtwTz-0005f7-UF for 66615@debbugs.gnu.org; Fri, 20 Oct 2023 16:52:42 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2436A100187; Fri, 20 Oct 2023 16:52:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1697835121; bh=QVdXfHlbXPHq8gWLkE5Hsom82WMoG2iTX1p8tM6brE0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bZa3jEekraHLyS9twwjXTSKORZzfIE8OEI4zOFOFVVWCdkFCVGoEVfdINfsEPdkLj NJ9yhYiaAhRCO+mxYw3IbjXIpv6uniD//OTVWOSgcFCk8CX2fEunBK53X1jv6n0AMA 9pBXmCT65wY1gfDrrhv5qox+iCJ41NMGdpwyNAf4LnBvOdeVA228XeoVsRuEg1jSA0 7l2sW11xzDU+ZJ46mWghmaSw1lzNVTM8fg2qMDT7IxCA0bUvENWFXXmSpyobPtWDdV F+lHgSq3/fnM1yV0jMx2gxBmUua6w8JtJeaOQpXT6k0DxntJb3aljkJgNK3LJ5JVUs R7C9Ld98tTI4A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 96D111000A3; Fri, 20 Oct 2023 16:52:01 -0400 (EDT) Received: from pastel (unknown [45.72.216.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6D4291204B2; Fri, 20 Oct 2023 16:52:01 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Andrea Corallo's message of "Fri, 20 Oct 2023 11:42:10 -0400") Message-ID: References: Date: Fri, 20 Oct 2023 16:51:54 -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.154 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > (null boolean symbol list sequence atom) is not a linearization of the > DAG, AFAIK it is. A linearization can be "depth first" or "breadth" first or any mix of it. It's basically any total order compatible with the partial order imposed by the DAG. > is just (TYPE . SUPERTYPES) where SUPERTYPES have no specific > order. Am I wrong? The order is from most specific to least specific. For types which are "incomparable", the choice is a judgment call. The above ordering seems acceptable to me since `atom` is arguably a larger type than `sequence`, but (null boolean symbol atom list sequence) is acceptable as well. This said, in general we'd like to avoid situations where type T1 appears before type T2 in one case and after it in another (it may not always be avoidable, sadly). And `atom` appears after `sequence` in cases like `vector` and `string`, so I think we should prefer (null boolean symbol list sequence atom) over (null boolean symbol atom list sequence) > How can current code (say dispatch on builtin types) work if we can't > infer if 'sequence' is higher or lower in the hierarchy respect > to 'list'? The linearization is specific to a given type, so we use the ordering provided by `cl--typeof-types` and we never care to know the full DAG. [ BTW, we should be able to infer that `list` is lower because every time it appears in `cl--typeof-types` it is always followed by `sequence`. ] > I think the original idea (as expressed by the doc) of having "the list > of its supertypes from the most specific to least specific" works for > reconstructing the DAG if we have one entry per path to the top, say: > > (null boolean symbol atom) > (null list sequence) > (cons list sequence) Indeed. But then it doesn't say how to make this into a total order when `cl-defmethod` needs to decide which method should come first. IOW, there is supposedly a DAG, but until now we've never actually needed the DAG itself, instead we've needed only a linearization of the ancestors of the leaves of that DAG, which is what `cl--typeof-types` stores. If you need the DAG, then maybe we need to store more info (tho I still suspect we should be able to extract that info from `cl--typeof-types`). Stefan From unknown Fri Jun 20 07:23:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Oct 2023 07:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66615 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169795824016844 (code B ref 66615); Sun, 22 Oct 2023 07:04:01 +0000 Received: (at 66615) by debbugs.gnu.org; 22 Oct 2023 07:04:00 +0000 Received: from localhost ([127.0.0.1]:45421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1quSVD-0004Nb-O3 for submit@debbugs.gnu.org; Sun, 22 Oct 2023 03:04:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1quSV9-0004NJ-5J for 66615@debbugs.gnu.org; Sun, 22 Oct 2023 03:03:58 -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 ) id 1quSUb-0004XN-FJ; Sun, 22 Oct 2023 03:03:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=47Cq7nVuNMQKB172IrPX5cYmIADNtO07+NYM6GDgiN8=; b=lKnA5ZFdkoBnmOlIGv6W cfTD50+Jx4Q5Coxgq9ZlBQa9v60c2CfeatOS3rrE6MkGkQva/6quf54A9VSN5mjIocNQ3N1D6wEi5 amwrvJrujR7h9/1tcQjmdYmUfmYbUu+bTzzBQ1e4fmjAoKS0/0k9PBHoeje3uAVKYHItnOXyXQUVR JdljthXHp1nOgLuDbLWqZLdOLUVPfsH0UtFBekq5evzIfexU4iZsqFnkLvzunmCpSO/N8z/W6HMQd p8aQz7qFpfCUCAmhDxc4W1yht6uKk8Y/pqsaScqigRIBNPm68qwYkEcaTJGr10wwDyn9L3wUnhe6q xUgywyN+ZhJBOw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1quSUZ-000645-Ln; Sun, 22 Oct 2023 03:03:21 -0400 From: Andrea Corallo In-Reply-To: (Stefan Monnier's message of "Fri, 20 Oct 2023 16:51:54 -0400") References: Date: Sun, 22 Oct 2023 03:03:19 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >> (null boolean symbol list sequence atom) is not a linearization of the >> DAG, > > AFAIK it is. A linearization can be "depth first" or "breadth" first or > any mix of it. It's basically any total order compatible with the > partial order imposed by the DAG. > >> is just (TYPE . SUPERTYPES) where SUPERTYPES have no specific >> order. Am I wrong? > > The order is from most specific to least specific. For types which are > "incomparable", the choice is a judgment call. The above ordering seems > acceptable to me since `atom` is arguably a larger type than `sequence`, > but > > (null boolean symbol atom list sequence) > > is acceptable as well. > > This said, in general we'd like to avoid situations where type T1 > appears before type T2 in one case and after it in another (it may not > always be avoidable, sadly). And `atom` appears after `sequence` in > cases like `vector` and `string`, so I think we should prefer > > (null boolean symbol list sequence atom) > > over > > (null boolean symbol atom list sequence) > >> How can current code (say dispatch on builtin types) work if we can't >> infer if 'sequence' is higher or lower in the hierarchy respect >> to 'list'? > > The linearization is specific to a given type, so we use the ordering > provided by `cl--typeof-types` and we never care to know the full DAG. > > [ BTW, we should be able to infer that `list` is lower because every > time it appears in `cl--typeof-types` it is always followed by > `sequence`. ] > >> I think the original idea (as expressed by the doc) of having "the list >> of its supertypes from the most specific to least specific" works for >> reconstructing the DAG if we have one entry per path to the top, say: >> >> (null boolean symbol atom) >> (null list sequence) >> (cons list sequence) > > Indeed. But then it doesn't say how to make this into a total order > when `cl-defmethod` needs to decide which method should come first. > > IOW, there is supposedly a DAG, but until now we've never actually > needed the DAG itself, instead we've needed only a linearization of the > ancestors of the leaves of that DAG, which is what > `cl--typeof-types` stores. > > If you need the DAG, then maybe we need to store more info (tho I still > suspect we should be able to extract that info from `cl--typeof-types`). Yep, I think I'll go for adding the DAG somewhere else, extratcting it from `cl--typeof-types` doesn't look trivial at all (if even possible) and its definition is at this point kind of weak IMO for that. Thanks Andrea