From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66615: 30.0.50; Inconsistent 'number-or-marker' type definition in the cl- machinery Date: Fri, 20 Oct 2023 16:51:54 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32324"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 66615@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 20 22:54:57 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qtwWH-0008Ew-M0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Oct 2023 22:54:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtwU2-0005G9-LV; Fri, 20 Oct 2023 16:52:38 -0400 Original-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 1qtwU0-0005Fw-Um for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2023 16:52:36 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qtwU0-0002M4-Lp for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2023 16:52:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtwUQ-0005g3-0P for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2023 16:53:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 66615-submit@debbugs.gnu.org id=B66615.169783516821795 (code B ref 66615); Fri, 20 Oct 2023 20:53:01 +0000 Original-Received: (at 66615) by debbugs.gnu.org; 20 Oct 2023 20:52:48 +0000 Original-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 Original-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 Original-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== Original-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) Original-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) In-Reply-To: (Andrea Corallo's message of "Fri, 20 Oct 2023 11:42:10 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272816 Archived-At: > (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