From unknown Thu Aug 14 21:21:58 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#65051 <65051@debbugs.gnu.org> To: bug#65051 <65051@debbugs.gnu.org> Subject: Status: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Reply-To: bug#65051 <65051@debbugs.gnu.org> Date: Fri, 15 Aug 2025 04:21:58 +0000 retitle 65051 internal_equal manipulates symbols with position without chec= king symbols-with-pos-enabled. reassign 65051 emacs submitter 65051 Alan Mackenzie severity 65051 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 04 10:00:45 2023 Received: (at submit) by debbugs.gnu.org; 4 Aug 2023 14:00:45 +0000 Received: from localhost ([127.0.0.1]:54452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRvMC-0008PK-Vh for submit@debbugs.gnu.org; Fri, 04 Aug 2023 10:00:45 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRvMB-0008P3-8s for submit@debbugs.gnu.org; Fri, 04 Aug 2023 10:00:44 -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 1qRvM3-00048x-PV for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 10:00:35 -0400 Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRvM1-0001j8-H2 for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 10:00:35 -0400 Received: (qmail 5183 invoked by uid 3782); 4 Aug 2023 16:00:29 +0200 Received: from acm.muc.de (pd953a874.dip0.t-ipconnect.de [217.83.168.116]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Aug 2023 16:00:29 +0200 Received: (qmail 1070 invoked by uid 1000); 4 Aug 2023 14:00:29 -0000 Date: Fri, 4 Aug 2023 14:00:29 +0000 To: bug-gnu-emacs@gnu.org Subject: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit 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.1 (/) Hello, Emacs. The code in question is in internal_equal (src/fns.c) ~37 lines from its start. We have: if (SYMBOL_WITH_POS_P (o1)) o1 = SYMBOL_WITH_POS_SYM (o1); if (SYMBOL_WITH_POS_P (o2)) o2 = SYMBOL_WITH_POS_SYM (o2); at the top level of the function. Thus (equal 'foo #) will return non-nil, regardless of the setting of symbols-with-pos-enabled. It should return non-nil only when that flag variable is non-nil. This is a bug. ######################################################################### A simple fix is: diff --git a/src/fns.c b/src/fns.c index bfd19e8c8f2..b1f0c4ecdd6 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, /* A symbol with position compares the contained symbol, and is `equal' to the corresponding ordinary symbol. */ - if (SYMBOL_WITH_POS_P (o1)) - o1 = SYMBOL_WITH_POS_SYM (o1); - if (SYMBOL_WITH_POS_P (o2)) - o2 = SYMBOL_WITH_POS_SYM (o2); + if (symbols_with_pos_enabled) + { + if (SYMBOL_WITH_POS_P (o1)) + o1 = SYMBOL_WITH_POS_SYM (o1); + if (SYMBOL_WITH_POS_P (o2)) + o2 = SYMBOL_WITH_POS_SYM (o2); + } if (BASE_EQ (o1, o2)) return true; -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 04 10:32:33 2023 Received: (at 65051) by debbugs.gnu.org; 4 Aug 2023 14:32:33 +0000 Received: from localhost ([127.0.0.1]:54490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRvqz-0000xh-41 for submit@debbugs.gnu.org; Fri, 04 Aug 2023 10:32:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRvqx-0000xS-CY for 65051@debbugs.gnu.org; Fri, 04 Aug 2023 10:32:32 -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 1qRvqp-00030X-N3; Fri, 04 Aug 2023 10:32:24 -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=Etyh553D4TJPRbFzmBKwJYLZBsTRzmpagoBFvtJ8UKc=; b=L/8jthU6ujvL DaP/LeVBFZjdd63CWo+TynbzFtwScICrPh5yULrSG1x6Lh47Okj3zchbfSjx5SKoh9zvHTbVvcTsu 3pMxJw29qckMGYT9Tc3JW4RayVQjHxMWPEtbHiMUsJ+Xubv5yAch6y6oRSDqxBOxiUG7Jr+59dfCp Cu8KPmYrlcgjoggFSZ7NEr3BUDlYu3TImC1/x88RkT3cQRyALMy+jmBKJFGM/pqdRs73+WeNW4Il6 O0eACxDbEP8Dlv3mZVYbZvnkPq1cpcL/yIyxUnYxWtBho9sjC9le+ns1RnCx1fX7vcNQsMtTxm56c WI1ToARVd2UmDPs6BI0lmg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRvqp-0007b5-6t; Fri, 04 Aug 2023 10:32:23 -0400 Date: Fri, 04 Aug 2023 17:32:35 +0300 Message-Id: <83leeqvpx8.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 4 Aug 2023 14:00:29 +0000) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) > Date: Fri, 4 Aug 2023 14:00:29 +0000 > From: Alan Mackenzie > > Hello, Emacs. > > The code in question is in internal_equal (src/fns.c) ~37 lines from its > start. We have: > > if (SYMBOL_WITH_POS_P (o1)) > o1 = SYMBOL_WITH_POS_SYM (o1); > if (SYMBOL_WITH_POS_P (o2)) > o2 = SYMBOL_WITH_POS_SYM (o2); > > at the top level of the function. Thus > > (equal 'foo #) > > will return non-nil, regardless of the setting of > symbols-with-pos-enabled. It should return non-nil only when that flag > variable is non-nil. This is a bug. > > ######################################################################### > > A simple fix is: What will happen to the comparison in internal_equal when symbols_with_pos_enabled is zero and the two objects have different positions, or one has a position, the other doesn't? And which branch are you proposing this change for? From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 04 11:00:07 2023 Received: (at 65051) by debbugs.gnu.org; 4 Aug 2023 15:00:07 +0000 Received: from localhost ([127.0.0.1]:54511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRwHe-0001rg-N7 for submit@debbugs.gnu.org; Fri, 04 Aug 2023 11:00:06 -0400 Received: from mx3.muc.de ([193.149.48.5]:56802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRwHd-0001qb-6b for 65051@debbugs.gnu.org; Fri, 04 Aug 2023 11:00:06 -0400 Received: (qmail 74014 invoked by uid 3782); 4 Aug 2023 16:59:59 +0200 Received: from acm.muc.de (pd953a874.dip0.t-ipconnect.de [217.83.168.116]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Aug 2023 16:59:59 +0200 Received: (qmail 1465 invoked by uid 1000); 4 Aug 2023 14:59:58 -0000 Date: Fri, 4 Aug 2023 14:59:58 +0000 To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83leeqvpx8.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83leeqvpx8.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (-) Hello, Eli. On Fri, Aug 04, 2023 at 17:32:35 +0300, Eli Zaretskii wrote: > > Date: Fri, 4 Aug 2023 14:00:29 +0000 > > From: Alan Mackenzie > > Hello, Emacs. > > The code in question is in internal_equal (src/fns.c) ~37 lines from its > > start. We have: > > if (SYMBOL_WITH_POS_P (o1)) > > o1 = SYMBOL_WITH_POS_SYM (o1); > > if (SYMBOL_WITH_POS_P (o2)) > > o2 = SYMBOL_WITH_POS_SYM (o2); > > at the top level of the function. Thus > > (equal 'foo #) > > will return non-nil, regardless of the setting of > > symbols-with-pos-enabled. It should return non-nil only when that flag > > variable is non-nil. This is a bug. > > ######################################################################### > > A simple fix is: > What will happen to the comparison in internal_equal when > symbols_with_pos_enabled is zero and the two objects have different > positions, or one has a position, the other doesn't? In these cases, equal will return nil. This is correct. In the other case, when two symbols with position have the same base symbol and the same position, yet aren't identical, this will also return nil, which is incorrect. Do you think this case is worth bothering about? It could easily be amended. > And which branch are you proposing this change for? master. It doesn't seem important enough for the release branch. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 04 11:27:49 2023 Received: (at 65051) by debbugs.gnu.org; 4 Aug 2023 15:27:49 +0000 Received: from localhost ([127.0.0.1]:54585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRwiT-0002h4-Co for submit@debbugs.gnu.org; Fri, 04 Aug 2023 11:27:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRwiS-0002gr-Gc for 65051@debbugs.gnu.org; Fri, 04 Aug 2023 11:27: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 1qRwiN-0003pj-1g; Fri, 04 Aug 2023 11:27:43 -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=On9PlJujmw7fSrlFQxK4jF2ESTZwSqehL8yMCWr4ACY=; b=I4RqH/SAyFVe QXwsIKAlP7v+DTnmUN9tVxYHqGcGFIODjYlpojM84uvr1UvkevrgZ/QiYOH6rvygUwFA5DQXYeyBF fQGCuw5vHJdyxMbhIoOQC3vyGxTWcXZZ4FBGQ9AikhqyLaHlhrN23QvruO5stFuD8Fc8DUd0lh9Hb SgZCKy6cKeGlzDsco4UlS9KfuhPLJ5GflQuzK1I2pleKnH+0XJy1dHg1tdtbBJhshV5fWxE8YNzcp KzusZufxxgQiaVq5grmqK1Vxm1PJwkvGES1GNSDaTTjL/G5yyCpKCdkF1tLJuZYz46s1H9f4GjuEg lg0SzwDsprgpse/MCr8sng==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRwiM-0002UD-HO; Fri, 04 Aug 2023 11:27:42 -0400 Date: Fri, 04 Aug 2023 18:27:55 +0300 Message-Id: <83h6pevnd0.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 4 Aug 2023 14:59:58 +0000) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: <83leeqvpx8.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (---) > Date: Fri, 4 Aug 2023 14:59:58 +0000 > Cc: 65051@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > What will happen to the comparison in internal_equal when > > symbols_with_pos_enabled is zero and the two objects have different > > positions, or one has a position, the other doesn't? > > In these cases, equal will return nil. This is correct. It is? I thought when symbols with position are disabled, symbols that are 'eq', but have different positions, should compare equal? Why not? > In the other case, when two symbols with position have the same base > symbol and the same position, yet aren't identical, this will also return > nil, which is incorrect. How can they be not identical if the symbols and the positions are the same? Or maybe I don't understand what you mean by "base symbol"? > > And which branch are you proposing this change for? > > master. It doesn't seem important enough for the release branch. OK. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 04 13:06:19 2023 Received: (at 65051) by debbugs.gnu.org; 4 Aug 2023 17:06:19 +0000 Received: from localhost ([127.0.0.1]:54671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRyFn-0008GF-6c for submit@debbugs.gnu.org; Fri, 04 Aug 2023 13:06:19 -0400 Received: from mx3.muc.de ([193.149.48.5]:60448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRyFk-0008G1-A6 for 65051@debbugs.gnu.org; Fri, 04 Aug 2023 13:06:17 -0400 Received: (qmail 21481 invoked by uid 3782); 4 Aug 2023 19:06:10 +0200 Received: from acm.muc.de (pd953a874.dip0.t-ipconnect.de [217.83.168.116]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Aug 2023 19:06:10 +0200 Received: (qmail 28134 invoked by uid 1000); 4 Aug 2023 17:06:10 -0000 Date: Fri, 4 Aug 2023 17:06:10 +0000 To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83h6pevnd0.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (-) Hello, Eli. On Fri, Aug 04, 2023 at 18:27:55 +0300, Eli Zaretskii wrote: > > Date: Fri, 4 Aug 2023 14:59:58 +0000 > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > What will happen to the comparison in internal_equal when > > > symbols_with_pos_enabled is zero and the two objects have different > > > positions, or one has a position, the other doesn't? > > In these cases, equal will return nil. This is correct. > It is? I thought when symbols with position are disabled, symbols > that are 'eq', but have different positions, should compare equal? > Why not? With symbols-with-pos-enabled nil, # is not EQ to #. Neither are these two objects `equal'. This is because the special, time consuming processing which makes them EQ or `equal' is enabled by that variable being bound to non-nil. That's the theory. In practice, the handling in internal_equal forgot to check for symbols-with-pos-enabled. That's what I want to fix, now. > > In the other case, when two symbols with position have the same base > > symbol and the same position, yet aren't identical, this will also return > > nil, which is incorrect. > How can they be not identical if the symbols and the positions are the > same? Or maybe I don't understand what you mean by "base symbol"? By "base symbol" I mean 'foo in #. By "identical" I meant that the two Lisp_Objects would have the same hex value (i.e. be EQ without symbols-with-pos-enabled), as contrasted to two distinct Lisp_Objects with the same base symbol, and the same position, i.e. should be `equal'. The way internal_equal is coded, only certain subtypes of Lisp_vectorlike have their innards compared. The other subtypes are simply assumed not `equal'. PVEC_SYMBOL_WITH_POS currently isn't among these subtypes, though this could be changed easily enough. > > > And which branch are you proposing this change for? > > master. It doesn't seem important enough for the release branch. > OK. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 04 14:01:28 2023 Received: (at 65051) by debbugs.gnu.org; 4 Aug 2023 18:01:28 +0000 Received: from localhost ([127.0.0.1]:54779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRz79-0001OS-Q5 for submit@debbugs.gnu.org; Fri, 04 Aug 2023 14:01:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRz77-0001OG-PZ for 65051@debbugs.gnu.org; Fri, 04 Aug 2023 14:01: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 1qRz72-0007Wa-9A; Fri, 04 Aug 2023 14:01:20 -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=6eOHH9ynqbewnjLhz50pXj0KRx2plH1p9OPg+Ijp1oM=; b=qH9EdNBOM74d XJ9n5qUoE0yZUKkCAmEzveVWL+S8sjN85WjVBi3xcCvN8MMaAdq/eYWeLAZ/8AN/R6Z+4Q7WKP2SQ /PdoMdWO43+1TGLNAOqTzE4cQbaFWEOAWzR+D3t9clM/893HfDHbMCcdHXRILQY+clhZy/TeHcG0u SpRzpjVrqX5+Yal8HCwKC6ASbVbx/2aKkGBViv31O7g0hUUIi1kXCCcPZA8EYsiwdFZ9WIUMGA3H/ ENsaz6wcQ+J02lhXvwltzdSPSZMlSNae0iC+EmRDI9qt5P70im/tughit7NFsRjjjtHb8rGCU5acz v/7QDaAMkJwxB5ujwB2WBw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRz71-00081m-3t; Fri, 04 Aug 2023 14:01:19 -0400 Date: Fri, 04 Aug 2023 21:01:30 +0300 Message-Id: <838raqvg91.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 4 Aug 2023 17:06:10 +0000) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) > Date: Fri, 4 Aug 2023 17:06:10 +0000 > Cc: 65051@debbugs.gnu.org > From: Alan Mackenzie > > On Fri, Aug 04, 2023 at 18:27:55 +0300, Eli Zaretskii wrote: > > > Date: Fri, 4 Aug 2023 14:59:58 +0000 > > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > > From: Alan Mackenzie > > > > > What will happen to the comparison in internal_equal when > > > > symbols_with_pos_enabled is zero and the two objects have different > > > > positions, or one has a position, the other doesn't? > > > > In these cases, equal will return nil. This is correct. > > > It is? I thought when symbols with position are disabled, symbols > > that are 'eq', but have different positions, should compare equal? > > Why not? > > With symbols-with-pos-enabled nil, # is not EQ to > #. Neither are these two objects `equal'. This is > because the special, time consuming processing which makes them EQ or > `equal' is enabled by that variable being bound to non-nil. But I thought that with symbols-with-pos-enabled OFF, we just ignore the positions? Truth is, neither the ELisp manual nor the doc string tell us what happens when this variable is nil, they only tell what happens when it's non-nil. So how about documenting that somewhere? > That's the theory. In practice, the handling in internal_equal forgot to > check for symbols-with-pos-enabled. That's what I want to fix, now. I understand, but I question the correctness of your proposed fix. And for now, I'm utterly confused regarding the expected semantics of these comparisons when symbols-with-pos-enabled is nil. > > > In the other case, when two symbols with position have the same base > > > symbol and the same position, yet aren't identical, this will also return > > > nil, which is incorrect. > > > How can they be not identical if the symbols and the positions are the > > same? Or maybe I don't understand what you mean by "base symbol"? > > By "base symbol" I mean 'foo in #. By "identical" I > meant that the two Lisp_Objects would have the same hex value (i.e. be > EQ without symbols-with-pos-enabled), as contrasted to two distinct > Lisp_Objects with the same base symbol, and the same position, i.e. > should be `equal'. So we can have two different copies of #, such that their hex values are different? Isn't that a bug? why don't we conflate such identical symbols? From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 06:45:48 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 10:45:48 +0000 Received: from localhost ([127.0.0.1]:55773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSEn5-0004rF-Bu for submit@debbugs.gnu.org; Sat, 05 Aug 2023 06:45:48 -0400 Received: from mx3.muc.de ([193.149.48.5]:35070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSEn3-0004r0-AD for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 06:45:46 -0400 Received: (qmail 39781 invoked by uid 3782); 5 Aug 2023 12:45:38 +0200 Received: from acm.muc.de (p4fe15973.dip0.t-ipconnect.de [79.225.89.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Aug 2023 12:45:38 +0200 Received: (qmail 3794 invoked by uid 1000); 5 Aug 2023 10:45:37 -0000 Date: Sat, 5 Aug 2023 10:45:37 +0000 To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838raqvg91.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (-) Hello, Eli. On Fri, Aug 04, 2023 at 21:01:30 +0300, Eli Zaretskii wrote: > > Date: Fri, 4 Aug 2023 17:06:10 +0000 > > Cc: 65051@debbugs.gnu.org > > From: Alan Mackenzie > > On Fri, Aug 04, 2023 at 18:27:55 +0300, Eli Zaretskii wrote: > > > > Date: Fri, 4 Aug 2023 14:59:58 +0000 > > > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > > > From: Alan Mackenzie > > > > > What will happen to the comparison in internal_equal when > > > > > symbols_with_pos_enabled is zero and the two objects have different > > > > > positions, or one has a position, the other doesn't? > > > > In these cases, equal will return nil. This is correct. > > > It is? I thought when symbols with position are disabled, symbols > > > that are 'eq', but have different positions, should compare equal? > > > Why not? > > With symbols-with-pos-enabled nil, # is not EQ to > > #. Neither are these two objects `equal'. This is > > because the special, time consuming processing which makes them EQ or > > `equal' is enabled by that variable being bound to non-nil. > But I thought that with symbols-with-pos-enabled OFF, we just ignore > the positions? Truth is, neither the ELisp manual nor the doc string > tell us what happens when this variable is nil, they only tell what > happens when it's non-nil. So how about documenting that somewhere? OK, please see the patch below. > > That's the theory. In practice, the handling in internal_equal forgot to > > check for symbols-with-pos-enabled. That's what I want to fix, now. > I understand, but I question the correctness of your proposed fix. > And for now, I'm utterly confused regarding the expected semantics of > these comparisons when symbols-with-pos-enabled is nil. > > > > In the other case, when two symbols with position have the same base > > > > symbol and the same position, yet aren't identical, this will also return > > > > nil, which is incorrect. > > > How can they be not identical if the symbols and the positions are the > > > same? Or maybe I don't understand what you mean by "base symbol"? > > By "base symbol" I mean 'foo in #. By "identical" I > > meant that the two Lisp_Objects would have the same hex value (i.e. be > > EQ without symbols-with-pos-enabled), as contrasted to two distinct > > Lisp_Objects with the same base symbol, and the same position, i.e. > > should be `equal'. > So we can have two different copies of #, such that > their hex values are different? Isn't that a bug? why don't we > conflate such identical symbols? No, it's not a bug, anymore than having two `equal' copies of '(a b c) would be a bug. It's vanishingly unlikely to happen in practice. I think it could only happen if a user creates a SWP with something like (setq bar (position-symbol 'foo 42)) , when there is already such a SWP created by read-positioning-symbols. Or, perhaps, if reading one function produced a certain SWP which hangs around in a variable such as cl--labels-convert-cache, and reading the next function produces another SWP which happens to have the same bare symbol and position. Anyway, I've added code (in that patch below) to check two SWPs properly in the event of symbols-with-pos-enabled being nil. As already discussed, this is intended for master, not the release branch. diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi index 34db0caf3a8..a6ecfe896ad 100644 --- a/doc/lispref/symbols.texi +++ b/doc/lispref/symbols.texi @@ -784,9 +784,11 @@ Symbols with Position @cindex bare symbol A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, together with an unsigned integer called the @dfn{position}. These -objects are intended for use by the byte compiler, which records in +objects are for the use of the byte compiler, which records in them the position of each symbol occurrence and uses those positions -in warning and error messages. +in warning and error messages. They shouldn't normally be used +otherwise. Doing so can cause unexpected results with basic Emacs +functions such as @code{eq} and @code{equal}. The printed representation of a symbol with position uses the hash notation outlined in @ref{Printed Representation}. It looks like @@ -798,11 +800,20 @@ Symbols with Position For most purposes, when the flag variable @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with -positions behave just as bare symbols do. For example, @samp{(eq -# foo)} has a value @code{t} when that variable -is set (but @code{nil} when it isn't set). Most of the time in Emacs this -variable is @code{nil}, but the byte compiler binds it to @code{t} -when it runs. +positions behave just as their bare symbols do. For example, +@samp{(eq # foo)} has a value @code{t} when the +variable is set; likewise, @code{equal} will treat a symbol with +position argument as its bare symbol. + +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with +position continue to exist, but do not behave as symbols, or have the +other useful properties outlined in the previous paragraph. @code{eq} +returns @code{t} when given identical arguments, and @code{equal} +returns @code{t} when given arguments with @code{equal} components. + +Most of the time in Emacs @code{symbols-with-pos-enabled} is +@code{nil}, but the byte compiler and the native compiler bind it to +@code{t} when they run. Typically, symbols with position are created by the byte compiler calling the reader function @code{read-positioning-symbols} @@ -820,7 +831,7 @@ Symbols with Position a symbol with position, ignoring the position. @end defvar -@defun symbol-with-pos-p symbol. +@defun symbol-with-pos-p symbol This function returns @code{t} if @var{symbol} is a symbol with position, @code{nil} otherwise. @end defun diff --git a/src/fns.c b/src/fns.c index bfd19e8c8f2..d47098c8791 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, /* A symbol with position compares the contained symbol, and is `equal' to the corresponding ordinary symbol. */ - if (SYMBOL_WITH_POS_P (o1)) - o1 = SYMBOL_WITH_POS_SYM (o1); - if (SYMBOL_WITH_POS_P (o2)) - o2 = SYMBOL_WITH_POS_SYM (o2); + if (symbols_with_pos_enabled) + { + if (SYMBOL_WITH_POS_P (o1)) + o1 = SYMBOL_WITH_POS_SYM (o1); + if (SYMBOL_WITH_POS_P (o2)) + o2 = SYMBOL_WITH_POS_SYM (o2); + } if (BASE_EQ (o1, o2)) return true; @@ -2824,8 +2827,8 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, if (ASIZE (o2) != size) return false; - /* Compare bignums, overlays, markers, and boolvectors - specially, by comparing their values. */ + /* Compare bignums, overlays, markers, boolvectors, and + symbols with position specially, by comparing their values. */ if (BIGNUMP (o1)) return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) == 0; if (OVERLAYP (o1)) @@ -2857,6 +2860,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, if (TS_NODEP (o1)) return treesit_node_eq (o1, o2); #endif + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. */ + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, + XSYMBOL_WITH_POS (o2)->sym, + equal_kind, depth + 1, ht) + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, + XSYMBOL_WITH_POS (o2)->pos, + equal_kind, depth + 1, ht)); /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 06:57:44 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 10:57:44 +0000 Received: from localhost ([127.0.0.1]:55795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSEye-0005F7-Fx for submit@debbugs.gnu.org; Sat, 05 Aug 2023 06:57:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSEyd-0005Ev-7e for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 06:57:43 -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 1qSEyW-0004bz-P9; Sat, 05 Aug 2023 06:57:36 -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=RHKEV5lclw4ETtKFBN7dMJT/zoGMxSAOPHJKG3TvWD4=; b=pJsUGj6OpHLo Lu7vFmv7hua+OXyercOQ5aEb9JjvbZvbRS30oHoCtzK57QTNuVBsoMvT0WdPGekE/J267vaCmY13R kPf+pJKlzsUhnjTMMlD+jRsehRz8MtdxfheqOo7J/TFJyX7HP5ebh/LGUzQmwpXq84XJociQuUIFz KJg1pmisYMCkeOYc8ctztm33n4k9qKsrlC2VGzLG/o2nPXTyLAlzPAHnLvDRv4ASxJvPHURYGnm5y dbLVxybxw0U6c2FDOHm85wA9WXE0gTIDlgh097l5EjDuLIlHGvrZLifeQEDda0ZbTHLsiCMbKkpvM KpxAdfxelAH0ku8H3vnSIA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSEyW-0004Tc-1e; Sat, 05 Aug 2023 06:57:36 -0400 Date: Sat, 05 Aug 2023 13:57:50 +0300 Message-Id: <83r0ohsqmp.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 5 Aug 2023 10:45:37 +0000) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -3.3 (---) > Date: Sat, 5 Aug 2023 10:45:37 +0000 > Cc: 65051@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > > With symbols-with-pos-enabled nil, # is not EQ to > > > #. Neither are these two objects `equal'. This is > > > because the special, time consuming processing which makes them EQ or > > > `equal' is enabled by that variable being bound to non-nil. > > > But I thought that with symbols-with-pos-enabled OFF, we just ignore > > the positions? Truth is, neither the ELisp manual nor the doc string > > tell us what happens when this variable is nil, they only tell what > > happens when it's non-nil. So how about documenting that somewhere? > > OK, please see the patch below. Thanks. > > > By "base symbol" I mean 'foo in #. By "identical" I > > > meant that the two Lisp_Objects would have the same hex value (i.e. be > > > EQ without symbols-with-pos-enabled), as contrasted to two distinct > > > Lisp_Objects with the same base symbol, and the same position, i.e. > > > should be `equal'. > > > So we can have two different copies of #, such that > > their hex values are different? Isn't that a bug? why don't we > > conflate such identical symbols? > > No, it's not a bug, anymore than having two `equal' copies of '(a b c) > would be a bug. But with symbols we store them in obarray, and obarray ought to find the existing slot for # and reuse it, rather than create a new slot? > Anyway, I've added code (in that patch below) to check two SWPs properly > in the event of symbols-with-pos-enabled being nil. > > As already discussed, this is intended for master, not the release > branch. Thanks. I added Stefan to the discussion, since I'd like another pair of eyes (with more knowledge about this than mine) to eyeball the changes before we install them. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 07:53:02 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 11:53:02 +0000 Received: from localhost ([127.0.0.1]:55997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSFqA-00012W-C8 for submit@debbugs.gnu.org; Sat, 05 Aug 2023 07:53:02 -0400 Received: from mx3.muc.de ([193.149.48.5]:37008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSFq7-000120-7H for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 07:53:00 -0400 Received: (qmail 16272 invoked by uid 3782); 5 Aug 2023 13:52:53 +0200 Received: from acm.muc.de (p4fe15973.dip0.t-ipconnect.de [79.225.89.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Aug 2023 13:52:52 +0200 Received: (qmail 21471 invoked by uid 1000); 5 Aug 2023 11:52:52 -0000 Date: Sat, 5 Aug 2023 11:52:52 +0000 To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> <83r0ohsqmp.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83r0ohsqmp.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de, 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: -1.0 (-) Hello, Eli. On Sat, Aug 05, 2023 at 13:57:50 +0300, Eli Zaretskii wrote: > > Date: Sat, 5 Aug 2023 10:45:37 +0000 > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie [ .... ] > > > So we can have two different copies of #, such that > > > their hex values are different? Isn't that a bug? why don't we > > > conflate such identical symbols? > > No, it's not a bug, anymore than having two `equal' copies of '(a b c) > > would be a bug. > But with symbols we store them in obarray, and obarray ought to find > the existing slot for # and reuse it, rather than > create a new slot? No, only the bare symbol is in the obarray. The symbol with position itself is a pseudovector, with contents (i) a bare symbol (a Lisp_Object "pointing at" the obarray) and (ii) the unsigned integer position. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 08:13:17 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 12:13:17 +0000 Received: from localhost ([127.0.0.1]:56020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSG9k-0001eR-M3 for submit@debbugs.gnu.org; Sat, 05 Aug 2023 08:13:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSG9i-0001eD-7j for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 08:13:16 -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 1qSG9c-0006F8-Fa; Sat, 05 Aug 2023 08:13:08 -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=JEahpuQpJp8eFQxsYVxmYtWKCgPgKh/nokHPaNeH2Jc=; b=J7ZCOAChULhQ yDq38Mg5f5a0C4YHGUXzqlJn41WpPUTdtPKYQf9sTc1otwMdDcyobK1wlXkl3ug6CIgZJ/GE5rgTI dPD4wv6t93UR6VF9W5UnbaMKJn/sH0FHOiKDRaZ44ya938PNis3aY6rdz7C+YkVQZ/XJ/p1lFP97r XXVR8qw9xbyjSXgbG3jEGvSApM2KisTeALsluVZ2+30oJtJEIA+ZlxoYREqOhRqj3vsZn/q7imX3r caG/vUlgENeZs1VtJHbss+ZygkChzdxRAXqFl1bYCXXGgcXVI3La3yLWu1oaLVzAqh/evh3voMvHx O2OAqmWcutCJj80XEEogMg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSG9b-0000Gs-KA; Sat, 05 Aug 2023 08:13:08 -0400 Date: Sat, 05 Aug 2023 15:13:22 +0300 Message-Id: <83leepsn4t.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 5 Aug 2023 11:52:52 +0000) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> <83r0ohsqmp.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de, monnier@iro.umontreal.ca 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 (---) > Date: Sat, 5 Aug 2023 11:52:52 +0000 > Cc: 65051@debbugs.gnu.org, Stefan Monnier , > acm@muc.de > From: Alan Mackenzie > > Hello, Eli. > > On Sat, Aug 05, 2023 at 13:57:50 +0300, Eli Zaretskii wrote: > > > Date: Sat, 5 Aug 2023 10:45:37 +0000 > > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > > From: Alan Mackenzie > > [ .... ] > > > > > So we can have two different copies of #, such that > > > > their hex values are different? Isn't that a bug? why don't we > > > > conflate such identical symbols? > > > > No, it's not a bug, anymore than having two `equal' copies of '(a b c) > > > would be a bug. > > > But with symbols we store them in obarray, and obarray ought to find > > the existing slot for # and reuse it, rather than > > create a new slot? > > No, only the bare symbol is in the obarray. The symbol with position > itself is a pseudovector, with contents (i) a bare symbol (a Lisp_Object > "pointing at" the obarray) and (ii) the unsigned integer position. Please document this factoid in the ELisp manual, I think it's very important, and having it undocumented is a Bad Thing. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 09:04:20 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 13:04:20 +0000 Received: from localhost ([127.0.0.1]:56072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSGxA-0005d7-3r for submit@debbugs.gnu.org; Sat, 05 Aug 2023 09:04:20 -0400 Received: from mx3.muc.de ([193.149.48.5]:39087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSGx4-0005cl-M8 for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 09:04:18 -0400 Received: (qmail 99035 invoked by uid 3782); 5 Aug 2023 15:04:08 +0200 Received: from acm.muc.de (p4fe15973.dip0.t-ipconnect.de [79.225.89.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Aug 2023 15:04:08 +0200 Received: (qmail 29141 invoked by uid 1000); 5 Aug 2023 13:04:07 -0000 Date: Sat, 5 Aug 2023 13:04:07 +0000 To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> <83r0ohsqmp.fsf@gnu.org> <83leepsn4t.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83leepsn4t.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de, monnier@iro.umontreal.ca 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 (-) Hello, Eli. On Sat, Aug 05, 2023 at 15:13:22 +0300, Eli Zaretskii wrote: > > Date: Sat, 5 Aug 2023 11:52:52 +0000 > > Cc: 65051@debbugs.gnu.org, Stefan Monnier , > > acm@muc.de > > From: Alan Mackenzie > > Hello, Eli. > > On Sat, Aug 05, 2023 at 13:57:50 +0300, Eli Zaretskii wrote: > > > > Date: Sat, 5 Aug 2023 10:45:37 +0000 > > > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > > > From: Alan Mackenzie > > [ .... ] > > > > > So we can have two different copies of #, such that > > > > > their hex values are different? Isn't that a bug? why don't we > > > > > conflate such identical symbols? > > > > No, it's not a bug, anymore than having two `equal' copies of '(a b c) > > > > would be a bug. > > > But with symbols we store them in obarray, and obarray ought to find > > > the existing slot for # and reuse it, rather than > > > create a new slot? > > No, only the bare symbol is in the obarray. The symbol with position > > itself is a pseudovector, with contents (i) a bare symbol (a Lisp_Object > > "pointing at" the obarray) and (ii) the unsigned integer position. > Please document this factoid in the ELisp manual, I think it's very > important, and having it undocumented is a Bad Thing. DONE. The change is near the top of the following patch, amended from the previous version. diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi index 34db0caf3a8..a828d303c04 100644 --- a/doc/lispref/symbols.texi +++ b/doc/lispref/symbols.texi @@ -784,9 +784,15 @@ Symbols with Position @cindex bare symbol A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, together with an unsigned integer called the @dfn{position}. These -objects are intended for use by the byte compiler, which records in -them the position of each symbol occurrence and uses those positions -in warning and error messages. +objects are stored internally much like vectors, and don't themselves +have entries in the obarray (though their bare symbols do; +@pxref{Creating Symbols}). + +Symbols with position are for the use of the byte compiler, which +records in them the position of each symbol occurrence and uses those +positions in warning and error messages. They shouldn't normally be +used otherwise. Doing so can cause unexpected results with basic +Emacs functions such as @code{eq} and @code{equal}. The printed representation of a symbol with position uses the hash notation outlined in @ref{Printed Representation}. It looks like @@ -798,11 +804,20 @@ Symbols with Position For most purposes, when the flag variable @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with -positions behave just as bare symbols do. For example, @samp{(eq -# foo)} has a value @code{t} when that variable -is set (but @code{nil} when it isn't set). Most of the time in Emacs this -variable is @code{nil}, but the byte compiler binds it to @code{t} -when it runs. +positions behave just as their bare symbols would. For example, +@samp{(eq # foo)} has a value @code{t} when the +variable is set; likewise, @code{equal} will treat a symbol with +position argument as its bare symbol. + +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with +position continue to exist, but do not behave as symbols, or have the +other useful properties outlined in the previous paragraph. @code{eq} +returns @code{t} when given identical arguments, and @code{equal} +returns @code{t} when given arguments with @code{equal} components. + +Most of the time in Emacs @code{symbols-with-pos-enabled} is +@code{nil}, but the byte compiler and the native compiler bind it to +@code{t} when they run. Typically, symbols with position are created by the byte compiler calling the reader function @code{read-positioning-symbols} @@ -820,7 +835,7 @@ Symbols with Position a symbol with position, ignoring the position. @end defvar -@defun symbol-with-pos-p symbol. +@defun symbol-with-pos-p symbol This function returns @code{t} if @var{symbol} is a symbol with position, @code{nil} otherwise. @end defun -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 09:13:07 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 13:13:08 +0000 Received: from localhost ([127.0.0.1]:56098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSH5f-0005rW-Kf for submit@debbugs.gnu.org; Sat, 05 Aug 2023 09:13:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSH5d-0005qw-EX for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 09:13:06 -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 1qSH5W-0002CC-KR; Sat, 05 Aug 2023 09:12:58 -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=A3XX5H/rImB32W/1LYTAwVRG754wzU9mFcCup6efip4=; b=EZInNDb7AMm1 XR3k/ifZYpCoDlb0KeWArdDHzQ80QhBjN26Iap/deabT7O7XqKMkm3T3TqY2S0UjWR79IzjF/GqAp zQrPE5xPXL6J0DXJsByrne00mFupJSlbsX6KxoBc/cY9+wlj0rSSwlml6W2XdzLObD7TjxBCSuBQv SVkjCJZH6Smfq/EHJ3vvgx6lRDoOTGNNqIP74CMzYmzJv8UbOOo109FdU4S2t3IoIrn48AHBQcb/V UslKf9c6XT0V/T4qFMhPQ9NFRghEQtQeTAa79WN8eJBf4JM/uvGK4XUj5ME95qtqq9PNaJ7X3kdLx FhIE/079Frukfy4rf0WHqQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSH5W-000713-41; Sat, 05 Aug 2023 09:12:58 -0400 Date: Sat, 05 Aug 2023 16:13:13 +0300 Message-Id: <838rapskd2.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 5 Aug 2023 13:04:07 +0000) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> <83r0ohsqmp.fsf@gnu.org> <83leepsn4t.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de, monnier@iro.umontreal.ca 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 (---) > Date: Sat, 5 Aug 2023 13:04:07 +0000 > Cc: 65051@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > From: Alan Mackenzie > > > > No, only the bare symbol is in the obarray. The symbol with position > > > itself is a pseudovector, with contents (i) a bare symbol (a Lisp_Object > > > "pointing at" the obarray) and (ii) the unsigned integer position. > > > Please document this factoid in the ELisp manual, I think it's very > > important, and having it undocumented is a Bad Thing. > > DONE. The change is near the top of the following patch, amended from > the previous version. LGTM, thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 10:40:38 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 14:40:38 +0000 Received: from localhost ([127.0.0.1]:57932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSISM-0000Kd-Ch for submit@debbugs.gnu.org; Sat, 05 Aug 2023 10:40:38 -0400 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:45235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSISG-0000KM-DV for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 10:40:36 -0400 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4f4b2bc1565so5118334e87.2 for <65051@debbugs.gnu.org>; Sat, 05 Aug 2023 07:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691246426; x=1691851226; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=yFdzjJMjIUVqoro/QAL4nhck2zyHqb/kgk2yaSCBjUQ=; b=TRtgIofjNF0u9Wo8m22lN+BS1E6aEAd4usTmXQoD38t8rGJ8oAkrALYNVXFzpKqyrf JC4RZnwUptpSLRYB5Ierta7pw4BPVkfdNhA4qtQybwKDXXenqFhqTtfVNk5hsR7dNZ+p PvLPxbpnNYcuPiMeYoxyPzGSXqwsZB7L2HMrscojT1FvEAK6ERU3/XSk8+FYhGhmcE1W NAmeZcvJPjGDyenvlEIMwUOm9vpTxaAHUFYagFkTfh0K5Ymdv4zuALQWCINeiaHEHeuk FvZ7qqptEY+zQGZcDl+VUvRCcuRIRbV9FVtoLwsxYpUuDFBldRx6V0/4fdVLCBnVCqqf UomQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691246426; x=1691851226; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yFdzjJMjIUVqoro/QAL4nhck2zyHqb/kgk2yaSCBjUQ=; b=FnGB8cGE9K22BNmSjOyBt7qR2fTZnVyDhyb+Amxvu81bbA2/eoeAnXkVmWEZYHlTvz HbPNHZIon414jeoErC5+G05u+9e3YBvnrBMBO+bhAGzhBSDThUl40mhaLBdGjMSo8Hmz Zl/w1QBwysgU4ciIi0CRGVLcbUucwxIQKiZ9kHqvvEU7gjZZGdDJrFxNGOPpSyRW595y CWQUIbsU0xJYZJNJbB1yok8AEm2lE2eHowCIV5KjkI/IMDjv7FUxa2XRz/au18Xh5nsw 2M1mePWDdYUOFErdYNF87XFVk3hXDtDLVbge/fsuMg9T1Mn+tIxVz+OHxPPju6ZUUgeo Vk/g== X-Gm-Message-State: AOJu0YzUBiaXLtVg4Y1acUnfIKjDv1g7JCFCwW5XBaHKBpd5Ew9zbr9y /QsPVUli/BGFyswEKEPJ4Bw= X-Google-Smtp-Source: AGHT+IFSR/Rfpts25P5PMHt8ZZFojlYak/fvLXqKQDp5cr5VnUdcE5Ty58tQDdO1/wi/DU5QWB+Z/g== X-Received: by 2002:a05:6512:1144:b0:4fe:3a57:7c98 with SMTP id m4-20020a056512114400b004fe3a577c98mr3141412lfg.32.1691246426027; Sat, 05 Aug 2023 07:40:26 -0700 (PDT) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id v13-20020a056512048d00b004fb9fe34c27sm780407lfq.92.2023.08.05.07.40.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2023 07:40:24 -0700 (PDT) From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-Id: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> Date: Sat, 5 Aug 2023 16:40:23 +0200 To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) Alan, could you produce a combined patch that includes your proposal so = far (and all tests)? From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 12:59:36 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 16:59:36 +0000 Received: from localhost ([127.0.0.1]:58042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSKcq-0006gX-Io for submit@debbugs.gnu.org; Sat, 05 Aug 2023 12:59:36 -0400 Received: from mx3.muc.de ([193.149.48.5]:45944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSKcm-0006gD-GF for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 12:59:35 -0400 Received: (qmail 66699 invoked by uid 3782); 5 Aug 2023 18:59:26 +0200 Received: from acm.muc.de (p4fe15973.dip0.t-ipconnect.de [79.225.89.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Aug 2023 18:59:26 +0200 Received: (qmail 30941 invoked by uid 1000); 5 Aug 2023 16:59:24 -0000 Date: Sat, 5 Aug 2023 16:59:24 +0000 To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) Hello, Mattias. On Sat, Aug 05, 2023 at 16:40:23 +0200, Mattias Engdegård wrote: > Alan, could you produce a combined patch that includes your proposal > so far (and all tests)? I've already published what I have so far on the bug list. I'll amend fns-tests.el hopefully this evening, maybe tomorrow. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 13:02:18 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 17:02:18 +0000 Received: from localhost ([127.0.0.1]:58046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSKfS-0006n5-0v for submit@debbugs.gnu.org; Sat, 05 Aug 2023 13:02:18 -0400 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:58780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSKfO-0006mk-Nu for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 13:02:16 -0400 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2b9f0b7af65so48279341fa.1 for <65051@debbugs.gnu.org>; Sat, 05 Aug 2023 10:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691254929; x=1691859729; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=21p07/WijkjMzmXy+Iadpb8XBsLFFfP285bjF7VXxw4=; b=CJEXGD/cogAbJlIsSo1evzPM1GVsFbQ9hh23ODDtsA9cck2I1cSHqTbHF2EdAq23xA I0yp/p5MoO5pVI9paiAtuk/nbHrL1iZ3NUtxnnRpLx8JBfC/wSHlaoXe42KwHzITfxZf 2yjAkqTT12758nv78H9LLpX290w2v8Q/xfbQsSzJQoR8OGcdmkZkGj8xu4y3N2V8+5Rt cGxAbQG0w/yao5PTSF8IReyurR9FnnEzwOGHk+Dws9SKpWH49rC8KH4BDPTCfGmLQbGU tJgg7ymAF3dZJ8jrpUGwRS1pxb9x5TFGaTmo8id8G4bbmqKVjWqRn3Tl4xdpq8vH+iVK c8Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691254929; x=1691859729; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=21p07/WijkjMzmXy+Iadpb8XBsLFFfP285bjF7VXxw4=; b=KUFS/PJEz8PDlJ+JLi1Ay/Nby3BWcWWuQkkCKFIw1FRvPguKZUgdwrAyVl4a7lsvDB ADHum3aOKFtM9AI3SBDDhWYQLFYeO2ghkgFBRel/Rw9x/jbinRHn36WA7v4mhz4oiIq0 KV7jOdnYa4Tn0Ui90IwQIW0kpb7dSy49A0CAa188wqvTN/bpAZAFrQBIGeWl/kCFY6hc 5MxVdhAXtvZbj2tlciwcoWfY00l0zzQX+UTks8vOELtDd/NM72xZDUkfpPx52zETRSTg QpX/iXjpfqfQmUMfs3wpvxY5aG9VATXxQds3l4L+7suu3+2UDqJ2EtMCpdjl6jVKooKD HgGA== X-Gm-Message-State: AOJu0YysVZ175bDplsBoaOzeHLLS1/fg1EVFtAPzr3qZ5Q3kroT5V0Ig kXNi92GnpOi1p6cCan4CN7w= X-Google-Smtp-Source: AGHT+IGx6bxEqYuCZfBEkc5r0T+jTBGTHHZ0m/5KrRK//EqiJmyk8l/YqU/NkX9Aq6fKff6DjYAgBg== X-Received: by 2002:a2e:9211:0:b0:2b8:377a:22f1 with SMTP id k17-20020a2e9211000000b002b8377a22f1mr4009423ljg.32.1691254928378; Sat, 05 Aug 2023 10:02:08 -0700 (PDT) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id f22-20020a2e3816000000b002ba13fec4a0sm953792lja.59.2023.08.05.10.02.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2023 10:02:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Sat, 5 Aug 2023 19:02:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) 5 aug. 2023 kl. 18.59 skrev Alan Mackenzie : > I've already published what I have so far on the bug list. I'll amend > fns-tests.el hopefully this evening, maybe tomorrow. Thank you. Take your time, I'm in no hurry. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 05 17:07:36 2023 Received: (at 65051) by debbugs.gnu.org; 5 Aug 2023 21:07:36 +0000 Received: from localhost ([127.0.0.1]:58267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSOUq-0007JF-Ab for submit@debbugs.gnu.org; Sat, 05 Aug 2023 17:07:36 -0400 Received: from mx3.muc.de ([193.149.48.5]:53308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSOUl-0007Iz-Ql for 65051@debbugs.gnu.org; Sat, 05 Aug 2023 17:07:35 -0400 Received: (qmail 50921 invoked by uid 3782); 5 Aug 2023 23:07:25 +0200 Received: from acm.muc.de (p4fe15973.dip0.t-ipconnect.de [79.225.89.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Aug 2023 23:07:25 +0200 Received: (qmail 20304 invoked by uid 1000); 5 Aug 2023 21:07:24 -0000 Date: Sat, 5 Aug 2023 21:07:24 +0000 To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) Hello, Mattias. On Sat, Aug 05, 2023 at 16:40:23 +0200, Mattias Engdegård wrote: > Alan, could you produce a combined patch that includes your proposal so far (and all tests)? Here it is: diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi index 34db0caf3a8..a828d303c04 100644 --- a/doc/lispref/symbols.texi +++ b/doc/lispref/symbols.texi @@ -784,9 +784,15 @@ Symbols with Position @cindex bare symbol A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, together with an unsigned integer called the @dfn{position}. These -objects are intended for use by the byte compiler, which records in -them the position of each symbol occurrence and uses those positions -in warning and error messages. +objects are stored internally much like vectors, and don't themselves +have entries in the obarray (though their bare symbols do; +@pxref{Creating Symbols}). + +Symbols with position are for the use of the byte compiler, which +records in them the position of each symbol occurrence and uses those +positions in warning and error messages. They shouldn't normally be +used otherwise. Doing so can cause unexpected results with basic +Emacs functions such as @code{eq} and @code{equal}. The printed representation of a symbol with position uses the hash notation outlined in @ref{Printed Representation}. It looks like @@ -798,11 +804,20 @@ Symbols with Position For most purposes, when the flag variable @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with -positions behave just as bare symbols do. For example, @samp{(eq -# foo)} has a value @code{t} when that variable -is set (but @code{nil} when it isn't set). Most of the time in Emacs this -variable is @code{nil}, but the byte compiler binds it to @code{t} -when it runs. +positions behave just as their bare symbols would. For example, +@samp{(eq # foo)} has a value @code{t} when the +variable is set; likewise, @code{equal} will treat a symbol with +position argument as its bare symbol. + +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with +position continue to exist, but do not behave as symbols, or have the +other useful properties outlined in the previous paragraph. @code{eq} +returns @code{t} when given identical arguments, and @code{equal} +returns @code{t} when given arguments with @code{equal} components. + +Most of the time in Emacs @code{symbols-with-pos-enabled} is +@code{nil}, but the byte compiler and the native compiler bind it to +@code{t} when they run. Typically, symbols with position are created by the byte compiler calling the reader function @code{read-positioning-symbols} @@ -820,7 +835,7 @@ Symbols with Position a symbol with position, ignoring the position. @end defvar -@defun symbol-with-pos-p symbol. +@defun symbol-with-pos-p symbol This function returns @code{t} if @var{symbol} is a symbol with position, @code{nil} otherwise. @end defun diff --git a/src/fns.c b/src/fns.c index bfd19e8c8f2..d47098c8791 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, /* A symbol with position compares the contained symbol, and is `equal' to the corresponding ordinary symbol. */ - if (SYMBOL_WITH_POS_P (o1)) - o1 = SYMBOL_WITH_POS_SYM (o1); - if (SYMBOL_WITH_POS_P (o2)) - o2 = SYMBOL_WITH_POS_SYM (o2); + if (symbols_with_pos_enabled) + { + if (SYMBOL_WITH_POS_P (o1)) + o1 = SYMBOL_WITH_POS_SYM (o1); + if (SYMBOL_WITH_POS_P (o2)) + o2 = SYMBOL_WITH_POS_SYM (o2); + } if (BASE_EQ (o1, o2)) return true; @@ -2824,8 +2827,8 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, if (ASIZE (o2) != size) return false; - /* Compare bignums, overlays, markers, and boolvectors - specially, by comparing their values. */ + /* Compare bignums, overlays, markers, boolvectors, and + symbols with position specially, by comparing their values. */ if (BIGNUMP (o1)) return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) == 0; if (OVERLAYP (o1)) @@ -2857,6 +2860,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, if (TS_NODEP (o1)) return treesit_node_eq (o1, o2); #endif + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. */ + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, + XSYMBOL_WITH_POS (o2)->sym, + equal_kind, depth + 1, ht) + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, + XSYMBOL_WITH_POS (o2)->pos, + equal_kind, depth + 1, ht)); /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el index 79ae4393f40..9c09e4f0c33 100644 --- a/test/src/fns-tests.el +++ b/test/src/fns-tests.el @@ -98,6 +98,26 @@ (should-not (equal-including-properties #("a" 0 1 (k "v")) #("b" 0 1 (k "v"))))) +(ert-deftest fns-tests-equal-symbols-with-position () + "Test `eq' and `equal' on symbols with position." + (let ((foo1 (position-symbol 'foo 42)) + (foo2 (position-symbol 'foo 666)) + (foo3 (position-symbol 'foo 42))) + (let (symbols-with-pos-enabled) + (should (eq foo1 foo1)) + (should (equal foo1 foo1)) + (should-not (eq foo1 foo2)) + (should-not (equal foo1 foo2)) + (should-not (eq foo1 foo3)) + (should (equal foo1 foo3))) + (let ((symbols-with-pos-enabled t)) + (should (eq foo1 foo1)) + (should (equal foo1 foo1)) + (should (eq foo1 foo2)) + (should (equal foo1 foo2)) + (should (eq foo1 foo3)) + (should (equal foo1 foo3))))) + (ert-deftest fns-tests-reverse () (should-error (reverse)) (should-error (reverse 1)) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 06 09:37:36 2023 Received: (at 65051) by debbugs.gnu.org; 6 Aug 2023 13:37:36 +0000 Received: from localhost ([127.0.0.1]:58785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSdwt-0007er-Lo for submit@debbugs.gnu.org; Sun, 06 Aug 2023 09:37:36 -0400 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:61557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSdwp-0007eb-PM for 65051@debbugs.gnu.org; Sun, 06 Aug 2023 09:37:33 -0400 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b9c907bc68so56730661fa.2 for <65051@debbugs.gnu.org>; Sun, 06 Aug 2023 06:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691329046; x=1691933846; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=PxLy9vnbgu+KvPwBE4D8wpW2nOdnZJ/gUfyXlhxezSA=; b=Y5h0cdTQNn6mO1BfeHjvXhzzM71o0f/bW/RP17G4G+2596ohPq+uxDlgzQKsdKEGrs H4Puly0eRNQKq/1t4rewAYK7eDem7pZMvjq1Ulw+m/e0UJ+sjvvtnO6YdYKGqINbr3Yo IyfvT+mmT0Uizq2ZSFWcmlq14RsvOm69B8Z8aAjy2258JbAI8AbE3qbi/w277ENQb3Kt 13S6bfskI+AdI/VelNDAZZ9Jei4KlSXrr0Y5+/Xl3qB6cQWHSBzbSjqRtsWEi4b6vhf7 F8HVWR38heKQnh6gR0d4aJgXMsBPliqifynlgYtLcO19Hu+17dSOYyvtIefF0KRGZHKW ovow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691329046; x=1691933846; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PxLy9vnbgu+KvPwBE4D8wpW2nOdnZJ/gUfyXlhxezSA=; b=Q1tTp/fTD8faP212eF6kjJE7j66ugU9JJk70DtVCvye2ZVibX+M5hzm4kKFnED4wT6 c2xtWLtZPCTB/HqFDXx0MgA5GQsBGdcu6Ml2FOa0bhzO8hdZXdc5HwPKhELHzCMs9nBW EzLJm+CNc5WHD8Ijn0qqAe0l3z4k5mWSsJ/yjlQ8y2CHVfoiTKyIGE2C9bCHH3XvMo9z xEybp3OwX0F3g4/8QXSFsRRwKtIawz67nxuLd/oBaxQfv6HuXndSb6q/dW8AfHghSiG8 ToEMS99V6YpgQ/Msi+sLngJuEN3d+S20N47uIv9lkcJen/6vK+hQMRsmzyYRGl/fj709 RbgA== X-Gm-Message-State: AOJu0YydIb6t84GCuZRm3bq1ZjFmcew+MREqyT28pdgoH4vW7OL3lNHH lM2uBiD5QyWwQP4ACY/ZONc= X-Google-Smtp-Source: AGHT+IEJuDIU02aRoqxqlHnej46Dkt/Bef1W0Jtjhj5PxPe2F4MldLuazjmXBPiuOunFguCsyMzX7g== X-Received: by 2002:a2e:80da:0:b0:2b9:aa4d:3729 with SMTP id r26-20020a2e80da000000b002b9aa4d3729mr4791739ljg.28.1691329045480; Sun, 06 Aug 2023 06:37:25 -0700 (PDT) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id m8-20020a2e97c8000000b002b6fed37b18sm1331389ljj.101.2023.08.06.06.37.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Aug 2023 06:37:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Sun, 6 Aug 2023 15:37:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) 5 aug. 2023 kl. 23.07 skrev Alan Mackenzie : > diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi > index 34db0caf3a8..a828d303c04 100644 > --- a/doc/lispref/symbols.texi > +++ b/doc/lispref/symbols.texi > @@ -784,9 +784,15 @@ Symbols with Position > @cindex bare symbol > A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, > together with an unsigned integer called the @dfn{position}. These > -objects are intended for use by the byte compiler, which records in > -them the position of each symbol occurrence and uses those positions > -in warning and error messages. > +objects are stored internally much like vectors Not sure why we want to say how they are stored here. They can be stored = in bubble memory for all the user cares. > , and don't themselves > +have entries in the obarray (though their bare symbols do; > +@pxref{Creating Symbols}). > + > +Symbols with position are for the use of the byte compiler, which > +records in them the position of each symbol occurrence and uses those > +positions in warning and error messages. They shouldn't normally be > +used otherwise. Doing so can cause unexpected results with basic > +Emacs functions such as @code{eq} and @code{equal}. >=20 > The printed representation of a symbol with position uses the hash > notation outlined in @ref{Printed Representation}. It looks like > @@ -798,11 +804,20 @@ Symbols with Position >=20 > For most purposes, when the flag variable > @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with > -positions behave just as bare symbols do. For example, @samp{(eq > -# foo)} has a value @code{t} when that variable > -is set (but @code{nil} when it isn't set). Most of the time in Emacs = this > -variable is @code{nil}, but the byte compiler binds it to @code{t} > -when it runs. > +positions behave just as their bare symbols would. For example, > +@samp{(eq # foo)} has a value @code{t} when the > +variable is set; likewise, @code{equal} will treat a symbol with > +position argument as its bare symbol. > + > +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with > +position continue to exist, but do not behave as symbols, or have the > +other useful properties outlined in the previous paragraph. = @code{eq} > +returns @code{t} when given identical arguments, and @code{equal} > +returns @code{t} when given arguments with @code{equal} components. Since the components are bare symbols and fixnums, equality and identity = for them are equivalent, right? > + > +Most of the time in Emacs @code{symbols-with-pos-enabled} is > +@code{nil}, but the byte compiler and the native compiler bind it to > +@code{t} when they run. >=20 > Typically, symbols with position are created by the byte compiler > calling the reader function @code{read-positioning-symbols} > @@ -820,7 +835,7 @@ Symbols with Position > a symbol with position, ignoring the position. > @end defvar >=20 > -@defun symbol-with-pos-p symbol. > +@defun symbol-with-pos-p symbol > This function returns @code{t} if @var{symbol} is a symbol with > position, @code{nil} otherwise. > @end defun > diff --git a/src/fns.c b/src/fns.c > index bfd19e8c8f2..d47098c8791 100644 > --- a/src/fns.c > +++ b/src/fns.c > @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object = o2, enum equal_kind equal_kind, >=20 > /* A symbol with position compares the contained symbol, and is > `equal' to the corresponding ordinary symbol. */ > - if (SYMBOL_WITH_POS_P (o1)) > - o1 =3D SYMBOL_WITH_POS_SYM (o1); > - if (SYMBOL_WITH_POS_P (o2)) > - o2 =3D SYMBOL_WITH_POS_SYM (o2); > + if (symbols_with_pos_enabled) > + { > + if (SYMBOL_WITH_POS_P (o1)) > + o1 =3D SYMBOL_WITH_POS_SYM (o1); > + if (SYMBOL_WITH_POS_P (o2)) > + o2 =3D SYMBOL_WITH_POS_SYM (o2); > + } OK. This reduces the number of branches in the hot path for ordinary = (non-sympos) code by one while adding one to sym-pos code, and that = should be a fair trade-off. The new branch should be well-predicted but = is still consuming resources. > if (BASE_EQ (o1, o2)) > return true; > @@ -2824,8 +2827,8 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, = enum equal_kind equal_kind, > if (ASIZE (o2) !=3D size) > return false; >=20 > - /* Compare bignums, overlays, markers, and boolvectors > - specially, by comparing their values. */ > + /* Compare bignums, overlays, markers, boolvectors, and > + symbols with position specially, by comparing their values. = */ > if (BIGNUMP (o1)) > return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) =3D=3D = 0; > if (OVERLAYP (o1)) > @@ -2857,6 +2860,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, = enum equal_kind equal_kind, > if (TS_NODEP (o1)) > return treesit_node_eq (o1, o2); > #endif > + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. = */ > + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, > + XSYMBOL_WITH_POS (o2)->sym, > + equal_kind, depth + 1, ht) > + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, > + XSYMBOL_WITH_POS (o2)->pos, > + equal_kind, depth + 1, ht)); Why recurse here if the components are a bare symbol and a fixnum, = respectively? > /* Aside from them, only true vectors, char-tables, compiled > functions, and fonts (font-spec, font-entity, font-object) > diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el > index 79ae4393f40..9c09e4f0c33 100644 > --- a/test/src/fns-tests.el > +++ b/test/src/fns-tests.el > @@ -98,6 +98,26 @@ > (should-not (equal-including-properties #("a" 0 1 (k "v")) > #("b" 0 1 (k "v"))))) >=20 > +(ert-deftest fns-tests-equal-symbols-with-position () > + "Test `eq' and `equal' on symbols with position." > + (let ((foo1 (position-symbol 'foo 42)) > + (foo2 (position-symbol 'foo 666)) > + (foo3 (position-symbol 'foo 42))) > + (let (symbols-with-pos-enabled) > + (should (eq foo1 foo1)) Thank you! There is nothing wrong with the coverage of these tests with = respect to your changes. However we should make an effort to prevent the compiler from optimising = (eq X X) -> t etc, which it is completely entitled to doing, and also = test both the interpreted and compiled version of `eq` and `equal`. The test bytecomp--eq-symbols-with-pos-enabled already does most of this = for a different reason. Perhaps it can be extended to cover `equal` as = well? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 06 11:02:35 2023 Received: (at 65051) by debbugs.gnu.org; 6 Aug 2023 15:02:35 +0000 Received: from localhost ([127.0.0.1]:59787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSfH8-0001tk-MI for submit@debbugs.gnu.org; Sun, 06 Aug 2023 11:02:35 -0400 Received: from mx3.muc.de ([193.149.48.5]:28918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSfH3-0001tS-Uy for 65051@debbugs.gnu.org; Sun, 06 Aug 2023 11:02:33 -0400 Received: (qmail 86717 invoked by uid 3782); 6 Aug 2023 17:02:23 +0200 Received: from acm.muc.de (pd953a3d8.dip0.t-ipconnect.de [217.83.163.216]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 06 Aug 2023 17:02:23 +0200 Received: (qmail 10969 invoked by uid 1000); 6 Aug 2023 15:02:22 -0000 Date: Sun, 6 Aug 2023 15:02:22 +0000 To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) Hello, Mattias. On Sun, Aug 06, 2023 at 15:37:24 +0200, Mattias Engdegård wrote: > 5 aug. 2023 kl. 23.07 skrev Alan Mackenzie : > > diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi > > index 34db0caf3a8..a828d303c04 100644 > > --- a/doc/lispref/symbols.texi > > +++ b/doc/lispref/symbols.texi > > @@ -784,9 +784,15 @@ Symbols with Position > > @cindex bare symbol > > A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, > > together with an unsigned integer called the @dfn{position}. These > > -objects are intended for use by the byte compiler, which records in > > -them the position of each symbol occurrence and uses those positions > > -in warning and error messages. > > +objects are stored internally much like vectors > Not sure why we want to say how they are stored here. They can be > stored in bubble memory for all the user cares. The point is, they are _not_ stored in the obarray. Eli specifically asked me to clarify this point, yesterday. > > , and don't themselves > > +have entries in the obarray (though their bare symbols do; > > +@pxref{Creating Symbols}). > > + > > +Symbols with position are for the use of the byte compiler, which > > +records in them the position of each symbol occurrence and uses those > > +positions in warning and error messages. They shouldn't normally be > > +used otherwise. Doing so can cause unexpected results with basic > > +Emacs functions such as @code{eq} and @code{equal}. > > The printed representation of a symbol with position uses the hash > > notation outlined in @ref{Printed Representation}. It looks like > > @@ -798,11 +804,20 @@ Symbols with Position > > For most purposes, when the flag variable > > @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with > > -positions behave just as bare symbols do. For example, @samp{(eq > > -# foo)} has a value @code{t} when that variable > > -is set (but @code{nil} when it isn't set). Most of the time in Emacs this > > -variable is @code{nil}, but the byte compiler binds it to @code{t} > > -when it runs. > > +positions behave just as their bare symbols would. For example, > > +@samp{(eq # foo)} has a value @code{t} when the > > +variable is set; likewise, @code{equal} will treat a symbol with > > +position argument as its bare symbol. > > + > > +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with > > +position continue to exist, but do not behave as symbols, or have the > > +other useful properties outlined in the previous paragraph. @code{eq} > > +returns @code{t} when given identical arguments, and @code{equal} > > +returns @code{t} when given arguments with @code{equal} components. > Since the components are bare symbols and fixnums, equality and > identity for them are equivalent, right? No. If there are two distinct SWPs with the same bare symbol and the same position, they should be equal, but not eq. But the real point is to contrast how equal and eq work when symbols-with-pos-enabled is nil with when it is non-nil. > > + > > +Most of the time in Emacs @code{symbols-with-pos-enabled} is > > +@code{nil}, but the byte compiler and the native compiler bind it to > > +@code{t} when they run. > > Typically, symbols with position are created by the byte compiler > > calling the reader function @code{read-positioning-symbols} > > @@ -820,7 +835,7 @@ Symbols with Position > > a symbol with position, ignoring the position. > > @end defvar > > -@defun symbol-with-pos-p symbol. > > +@defun symbol-with-pos-p symbol > > This function returns @code{t} if @var{symbol} is a symbol with > > position, @code{nil} otherwise. > > @end defun > > diff --git a/src/fns.c b/src/fns.c > > index bfd19e8c8f2..d47098c8791 100644 > > --- a/src/fns.c > > +++ b/src/fns.c > > @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, > > /* A symbol with position compares the contained symbol, and is > > `equal' to the corresponding ordinary symbol. */ > > - if (SYMBOL_WITH_POS_P (o1)) > > - o1 = SYMBOL_WITH_POS_SYM (o1); > > - if (SYMBOL_WITH_POS_P (o2)) > > - o2 = SYMBOL_WITH_POS_SYM (o2); > > + if (symbols_with_pos_enabled) > > + { > > + if (SYMBOL_WITH_POS_P (o1)) > > + o1 = SYMBOL_WITH_POS_SYM (o1); > > + if (SYMBOL_WITH_POS_P (o2)) > > + o2 = SYMBOL_WITH_POS_SYM (o2); > > + } > OK. This reduces the number of branches in the hot path for ordinary > (non-sympos) code by one while adding one to sym-pos code, and that > should be a fair trade-off. The new branch should be well-predicted but > is still consuming resources. I did some simple timings on the old and new code, and the new code is not slower. See my post to Eli from yesterday evening [European time] on the bug #65017 thread. > > if (BASE_EQ (o1, o2)) > > return true; > > @@ -2824,8 +2827,8 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, > > if (ASIZE (o2) != size) > > return false; > > - /* Compare bignums, overlays, markers, and boolvectors > > - specially, by comparing their values. */ > > + /* Compare bignums, overlays, markers, boolvectors, and > > + symbols with position specially, by comparing their values. */ > > if (BIGNUMP (o1)) > > return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) == 0; > > if (OVERLAYP (o1)) > > @@ -2857,6 +2860,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, > > if (TS_NODEP (o1)) > > return treesit_node_eq (o1, o2); > > #endif > > + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. */ > > + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, > > + XSYMBOL_WITH_POS (o2)->sym, > > + equal_kind, depth + 1, ht) > > + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, > > + XSYMBOL_WITH_POS (o2)->pos, > > + equal_kind, depth + 1, ht)); > Why recurse here if the components are a bare symbol and a fixnum, > respectively? Maybe in case they might somehow be something else? The code in the patch prevents an error being thrown in such a case. The code should be run vanishingly seldomly anyhow, so it shouldn't matter much. > > /* Aside from them, only true vectors, char-tables, compiled > > functions, and fonts (font-spec, font-entity, font-object) > > diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el > > index 79ae4393f40..9c09e4f0c33 100644 > > --- a/test/src/fns-tests.el > > +++ b/test/src/fns-tests.el > > @@ -98,6 +98,26 @@ > > (should-not (equal-including-properties #("a" 0 1 (k "v")) > > #("b" 0 1 (k "v"))))) > > +(ert-deftest fns-tests-equal-symbols-with-position () > > + "Test `eq' and `equal' on symbols with position." > > + (let ((foo1 (position-symbol 'foo 42)) > > + (foo2 (position-symbol 'foo 666)) > > + (foo3 (position-symbol 'foo 42))) > > + (let (symbols-with-pos-enabled) > > + (should (eq foo1 foo1)) > Thank you! There is nothing wrong with the coverage of these tests with > respect to your changes. > However we should make an effort to prevent the compiler from > optimising (eq X X) -> t etc, which it is completely entitled to doing, > .... Why? (eq X X) is t in all circumstances, whether X is a symbol, a cons structure, or anything else. What am I missing, here? > .... and also test both the interpreted and compiled version of `eq` > and `equal`. They're the same code in both cases. I'm missing something here, too, I think. > The test bytecomp--eq-symbols-with-pos-enabled already does most of > this for a different reason. Perhaps it can be extended to cover > `equal` as well? I don't have such a test in my repository anywhere. Are you sure you wrote it right? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 06 23:30:45 2023 Received: (at 65051) by debbugs.gnu.org; 7 Aug 2023 03:30:45 +0000 Received: from localhost ([127.0.0.1]:60263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSqxA-0006n4-UH for submit@debbugs.gnu.org; Sun, 06 Aug 2023 23:30:45 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSqx6-0006mm-CP for 65051@debbugs.gnu.org; Sun, 06 Aug 2023 23:30:44 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9041C8076C; Sun, 6 Aug 2023 23:30:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691379029; bh=bv0d8VQy8yhRkDfFsZmZ21g8nVm84Fj9i9iV6fJzDr0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EN9yRCR9Y31YH+bm3YrpBGYxDi5Yv3nWZmBGA7Z1veyQ3r+DRDrvnAwx5Rsda9OBy bZXvRfH4oXGW8rrS86+7MPB8mA4JHrDvTBwtDqUo9Bc4gVTHN/cbF1wVv1x8leI1Bc fThXFa/gXVJgs+AqukJNTP90xUSmyInLQ8gmyfCtaKCbPEFuf3aqT2p3ew0kM2w24+ PGASwADOxHqYZ6XNwrIhtnwLK8cXV96NegkxB5vj2N6i2Hn76YPrpB1ZG65nbTvtam QAUgf2Qy9mLdWjbVxMsX4aJyZhW1sPssvAE6wjy7FHLvuqgQfx/A5hALmPeUDZp10p a9DcYHxzRKqBQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 544D4803D3; Sun, 6 Aug 2023 23:30:29 -0400 (EDT) Received: from alfajor (unknown [190.16.213.142]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5E43D12022E; Sun, 6 Aug 2023 23:30:28 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: (Alan Mackenzie's message of "Fri, 4 Aug 2023 14:00:29 +0000") Message-ID: References: Date: Sun, 06 Aug 2023 23:30:15 -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 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-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) > at the top level of the function. Thus > > (equal 'foo #) > > will return non-nil, regardless of the setting of > `symbols-with-pos-enabled`. It should return non-nil only when that > flag variable is non-nil. This is a bug. Could you explain why you think it's a bug? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 07 04:58:52 2023 Received: (at 65051) by debbugs.gnu.org; 7 Aug 2023 08:58:52 +0000 Received: from localhost ([127.0.0.1]:60542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSw4i-0007L8-A1 for submit@debbugs.gnu.org; Mon, 07 Aug 2023 04:58:52 -0400 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:42416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSw4g-0007Ku-8i for 65051@debbugs.gnu.org; Mon, 07 Aug 2023 04:58:51 -0400 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4fe44955decso5140228e87.1 for <65051@debbugs.gnu.org>; Mon, 07 Aug 2023 01:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691398724; x=1692003524; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=p5tZpBzGAmU8W4+8GZb5t659RzPPlAAdI2TbK8cH9zo=; b=dSJfDtzYYmb38T/ryi+wWAMRCDZYGMpDyDMZ7ZtObpNT+t/wOrncWtUZSgvh/oMpLk KBcsMDdCGfXvyVk/ldZKDa5wm2KuDm86vJ70gxoj4biR1zZQ1SXC9MFXAnwHaocQuSlz X0dY1W/8jpF+7TiBZNmc2YqZDyraOIkmqbJUhSCe9jotvrionOYZvMHUPBbtPC34/RHm BYbMsPzXQ3f7mKgpZq7G5DyK6BD7BCROiNaArFmF0r2wOnPdewzUBk3iLoe6ANGw5Hpv TlTvvecUa12HkX3ucmaKYCSdd3PzRn5yFGqdigf2Ez3VFCXp3HcyzQMmAKASHzpKSLlc UxdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691398724; x=1692003524; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=p5tZpBzGAmU8W4+8GZb5t659RzPPlAAdI2TbK8cH9zo=; b=ZUXOeo0zhzAlpO+mUf9cH+5mQVS48uQmAkwU0AOarWuFxIEHj2wSmW27q9zhYB4A89 TA7635G/S7YYupoyjANWwiYZidcNCCynm4rCnhxtya7lIecNAAwvBXybBaDHMApwKcca wDF2OK5eJi9Dlb25QXIhiZPMkaMVYvBIbCrwVdeXBIK4Uv765ZX/5Ej0msEKKaXFfnq+ 6OAawImxDmxpfiBSHS6pfkuPOcFMoW+9JcD0re9+boaBqOtETaKK09UkqT2K+SA7Om6G duVbcN2YZRlYNPKnPqOEq69wBGiRaixPElBoEt7aOHnEXYlz5IceQHRW3XM0ttuVVBbS llOQ== X-Gm-Message-State: AOJu0YyEwmC2ne8VJUHoKOehiKtyIVclSiSDyVnhQWKfDbXVzRUiR8WA dgbyeT8V9ZmRM0qg280AgDA= X-Google-Smtp-Source: AGHT+IGB81GXO2AaG6qrwhTa3HAM5qcINtiLJg9b2Mbd3UMKDVHOM3u++cdj87NYNIuopMkz5OOikQ== X-Received: by 2002:a05:6512:12cb:b0:4fb:c9e1:5286 with SMTP id p11-20020a05651212cb00b004fbc9e15286mr2714645lfg.7.1691398723724; Mon, 07 Aug 2023 01:58:43 -0700 (PDT) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id w10-20020a19c50a000000b004fe1f37035csm1411626lfe.224.2023.08.07.01.58.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2023 01:58:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Mon, 7 Aug 2023 10:58:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65A42652-DB4A-4FA6-8ADA-0D5BEB00F54C@gmail.com> References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) 6 aug. 2023 kl. 17.02 skrev Alan Mackenzie : >>> together with an unsigned integer called the @dfn{position}. These >>> -objects are intended for use by the byte compiler, which records in >>> -them the position of each symbol occurrence and uses those = positions >>> -in warning and error messages. >>> +objects are stored internally much like vectors >=20 >> Not sure why we want to say how they are stored here. They can be >> stored in bubble memory for all the user cares. >=20 > The point is, they are _not_ stored in the obarray. Eli specifically > asked me to clarify this point, yesterday. Oh that part is perfectly fine (thank you), we just don't need to say = that the sympos objects are stored "like vectors" -- that just confuses = the reader. >>> +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols = with >>> +position continue to exist, but do not behave as symbols, or have = the >>> +other useful properties outlined in the previous paragraph. = @code{eq} >>> +returns @code{t} when given identical arguments, and @code{equal} >>> +returns @code{t} when given arguments with @code{equal} components. >=20 >> Since the components are bare symbols and fixnums, equality and >> identity for them are equivalent, right? >=20 > No. If there are two distinct SWPs with the same bare symbol and the > same position, they should be equal, but not eq. But the real point = is > to contrast how equal and eq work when symbols-with-pos-enabled is nil > with when it is non-nil. I meant that the components of equal sympos objects aren't merely equal = but identical. (This is a very minor quibble; you can keep the text if = you like.) >> OK. This reduces the number of branches in the hot path for ordinary >> (non-sympos) code by one while adding one to sym-pos code, and that >> should be a fair trade-off. The new branch should be well-predicted = but >> is still consuming resources. >=20 > I did some simple timings on the old and new code, and the new code is > not slower. This is not easy to measure and details matter, but as I said -- there = is no reason to believe that your changes should be a regression in the = important measure, rather the opposite. >>> + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. = */ >>> + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, >>> + XSYMBOL_WITH_POS (o2)->sym, >>> + equal_kind, depth + 1, ht) >>> + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, >>> + XSYMBOL_WITH_POS (o2)->pos, >>> + equal_kind, depth + 1, ht)); >=20 >> Why recurse here if the components are a bare symbol and a fixnum, >> respectively? >=20 > Maybe in case they might somehow be something else? No, we must be able to assume that internal invariants hold when we = offer no way for them to be violated. Let's just change the calls to = BASE_EQ and be done with it. >> However we should make an effort to prevent the compiler from >> optimising (eq X X) -> t etc, which it is completely entitled to = doing, >> .... >=20 > Why? (eq X X) is t in all circumstances, whether X is a symbol, a = cons > structure, or anything else. What am I missing, here? If the compiler transforms (eq foo1 foo1) into t then the test won't = actually exercise the implementation of `eq`. >> .... and also test both the interpreted and compiled version of `eq` >> and `equal`. >=20 > They're the same code in both cases. I'm missing something here, too, = I > think. Byte-code doesn't call Feq, it uses its own implementation. They should = work identically but as we are checking edge cases here we'd better be = sure about that. >> The test bytecomp--eq-symbols-with-pos-enabled already does most of >> this for a different reason. Perhaps it can be extended to cover >> `equal` as well? >=20 > I don't have such a test in my repository anywhere. Are you sure you > wrote it right? It was added in 44d7fd3805. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 07 05:20:40 2023 Received: (at 65051) by debbugs.gnu.org; 7 Aug 2023 09:20:40 +0000 Received: from localhost ([127.0.0.1]:60578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSwPn-0007uS-TU for submit@debbugs.gnu.org; Mon, 07 Aug 2023 05:20:40 -0400 Received: from mx3.muc.de ([193.149.48.5]:60287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSwPh-0007u7-Py for 65051@debbugs.gnu.org; Mon, 07 Aug 2023 05:20:38 -0400 Received: (qmail 46468 invoked by uid 3782); 7 Aug 2023 11:20:26 +0200 Received: from acm.muc.de (pd953adbb.dip0.t-ipconnect.de [217.83.173.187]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Aug 2023 11:20:26 +0200 Received: (qmail 3265 invoked by uid 1000); 7 Aug 2023 09:20:25 -0000 Date: Mon, 7 Aug 2023 09:20:25 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (-) Hello, Stefan. On Sun, Aug 06, 2023 at 23:30:15 -0400, Stefan Monnier wrote: > > at the top level of the function. Thus > > (equal 'foo #) > > will return non-nil, regardless of the setting of > > `symbols-with-pos-enabled`. It should return non-nil only when that > > flag variable is non-nil. This is a bug. > Could you explain why you think it's a bug? When symbols-with-pos-enabled is non-nil, the two arguments to that equal call are equal. That is the point of s-w-p-e. When s-w-p-e is nil, and the "magic" is thus switched off, the two lisp objects have different type (the first is a symbol, the second is a pseudovector), thus cannot be equal. I think the amendments I've proposed for the elisp manual page "Symbols with Position" are now clearer about this sort of thing. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 07 05:45:05 2023 Received: (at 65051) by debbugs.gnu.org; 7 Aug 2023 09:45:05 +0000 Received: from localhost ([127.0.0.1]:60613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSwnQ-0008Vn-Sl for submit@debbugs.gnu.org; Mon, 07 Aug 2023 05:45:05 -0400 Received: from mx3.muc.de ([193.149.48.5]:60991) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSwnN-0008Up-KA for 65051@debbugs.gnu.org; Mon, 07 Aug 2023 05:45:03 -0400 Received: (qmail 73734 invoked by uid 3782); 7 Aug 2023 11:44:56 +0200 Received: from acm.muc.de (pd953adbb.dip0.t-ipconnect.de [217.83.173.187]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Aug 2023 11:44:55 +0200 Received: (qmail 3996 invoked by uid 1000); 7 Aug 2023 09:44:55 -0000 Date: Mon, 7 Aug 2023 09:44:55 +0000 To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> <65A42652-DB4A-4FA6-8ADA-0D5BEB00F54C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <65A42652-DB4A-4FA6-8ADA-0D5BEB00F54C@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) Hello, Mattias. On Mon, Aug 07, 2023 at 10:58:41 +0200, Mattias Engdegård wrote: > 6 aug. 2023 kl. 17.02 skrev Alan Mackenzie : > >>> together with an unsigned integer called the @dfn{position}. These > >>> -objects are intended for use by the byte compiler, which records in > >>> -them the position of each symbol occurrence and uses those positions > >>> -in warning and error messages. > >>> +objects are stored internally much like vectors > >> Not sure why we want to say how they are stored here. They can be > >> stored in bubble memory for all the user cares. > > The point is, they are _not_ stored in the obarray. Eli specifically > > asked me to clarify this point, yesterday. > Oh that part is perfectly fine (thank you), we just don't need to say > that the sympos objects are stored "like vectors" -- that just confuses > the reader. Why not? It's true, and I doubt it will cause confusion. I think we need to say something positive in that place (since we're following it with a negative). Perhaps you could suggest an alternative. > >>> +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with > >>> +position continue to exist, but do not behave as symbols, or have the > >>> +other useful properties outlined in the previous paragraph. @code{eq} > >>> +returns @code{t} when given identical arguments, and @code{equal} > >>> +returns @code{t} when given arguments with @code{equal} components. > >> Since the components are bare symbols and fixnums, equality and > >> identity for them are equivalent, right? > > No. If there are two distinct SWPs with the same bare symbol and the > > same position, they should be equal, but not eq. But the real point is > > to contrast how equal and eq work when symbols-with-pos-enabled is nil > > with when it is non-nil. > I meant that the components of equal sympos objects aren't merely equal > but identical. (This is a very minor quibble; you can keep the text if > you like.) The current proposed text has a more subtle intention. It says that eq and equal behave just like they always have done for everything when symbols-with-pos-enabled is nil. > >> OK. This reduces the number of branches in the hot path for ordinary > >> (non-sympos) code by one while adding one to sym-pos code, and that > >> should be a fair trade-off. The new branch should be well-predicted but > >> is still consuming resources. > > I did some simple timings on the old and new code, and the new code is > > not slower. > This is not easy to measure and details matter, but as I said -- there > is no reason to believe that your changes should be a regression in the > important measure, rather the opposite. Agreed. > >>> + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. */ > >>> + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, > >>> + XSYMBOL_WITH_POS (o2)->sym, > >>> + equal_kind, depth + 1, ht) > >>> + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, > >>> + XSYMBOL_WITH_POS (o2)->pos, > >>> + equal_kind, depth + 1, ht)); > >> Why recurse here if the components are a bare symbol and a fixnum, > >> respectively? > > Maybe in case they might somehow be something else? > No, we must be able to assume that internal invariants hold when we > offer no way for them to be violated. Let's just change the calls to > BASE_EQ and be done with it. OK, I think you're right, here, I'll change that. > >> However we should make an effort to prevent the compiler from > >> optimising (eq X X) -> t etc, which it is completely entitled to doing, > >> .... > > Why? (eq X X) is t in all circumstances, whether X is a symbol, a cons > > structure, or anything else. What am I missing, here? > If the compiler transforms (eq foo1 foo1) into t then the test won't > actually exercise the implementation of `eq`. Ah! You're talking about the tests. OK. In my tests, I timed (equal a b) where a and b were variables which were either equal or not. > >> .... and also test both the interpreted and compiled version of `eq` > >> and `equal`. > > They're the same code in both cases. I'm missing something here, too, I > > think. > Byte-code doesn't call Feq, it uses its own implementation. They should > work identically but as we are checking edge cases here we'd better be > sure about that. > >> The test bytecomp--eq-symbols-with-pos-enabled already does most of > >> this for a different reason. Perhaps it can be extended to cover > >> `equal` as well? > > I don't have such a test in my repository anywhere. Are you sure you > > wrote it right? > It was added in 44d7fd3805. OK. That commit is recent, then? If so, I'll see it soon. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 07 22:56:57 2023 Received: (at 65051) by debbugs.gnu.org; 8 Aug 2023 02:56:57 +0000 Received: from localhost ([127.0.0.1]:34645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTCu1-0002VF-2O for submit@debbugs.gnu.org; Mon, 07 Aug 2023 22:56:57 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTCtv-0002Ux-US for 65051@debbugs.gnu.org; Mon, 07 Aug 2023 22:56:55 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4F35C10009F; Mon, 7 Aug 2023 22:56:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691463405; bh=PMRzrgqX3HRgudknz8HvzvwcjbprgukzEUTsy3MymVY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ENOxro1dFTOaMkc1UDT1AySAag5vj0AzW57yQZYQcs6vhVdyvayTotE9MqUCc+Ujd 3aGlhjQvu2a0oMyl57/6Jq4wiIoI56CTf7KNje7OWHJ/X7zSOvTH8FK4jJ0Te/iWEZ 5SeH1nFqoUAYYEXUMletxW5DhZDCf/+QsrmWGr70JguZNGwV+qyYCutisyWd1GoOCC g2ctNkhB0EDjVQ6Nj48c1/Arjtge79bh04OfDfy5ZKCo5EiRB2lNXRf71J/Txz1X10 guvUPDLT8DdKm6e5u3JIhnS711frotp11PDkpFjW4FxEwAGdvyyzWsxzQZmSdtT42u NIkeQ5+6/VqIg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 43EE010007D; Mon, 7 Aug 2023 22:56:45 -0400 (EDT) Received: from alfajor (host56.201-252-107.telecom.net.ar [201.252.107.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 566C41202B9; Mon, 7 Aug 2023 22:56:44 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: (Alan Mackenzie's message of "Mon, 7 Aug 2023 09:20:25 +0000") Message-ID: References: Date: Mon, 07 Aug 2023 22:56:31 -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 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-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) >> Could you explain why you think it's a bug? > When symbols-with-pos-enabled is non-nil, the two arguments to that > equal call are equal. That is the point of s-w-p-e. AFAIK the point of the `symbols-with-pos-enabled` is to try and keep the performance impact of sympos under control, and that matters only for `eq`, so I don't think there's a strong reason here for `equal` to pay attention to it. > When s-w-p-e is nil, and the "magic" is thus switched off, the two lisp > objects have different type (the first is a symbol, the second is a > pseudovector), thus cannot be equal. "cannot" is obviously not the correct word here, since currently they are considered `equal`, so clearly they *can* be considered `equal`: it's easy to implement, and experience shows that "it works". So I'm still wondering why you think it's a bug. AFAICT whether sympos should be `equal` to others and/or to bare symbols is something we pretty much get to choose freely based on convenience: either the current behavior or the one you now advocate are perfectly acceptable and not bugs. As I said elsewhere, I'm not sure which choice is best, but at least we have some experience with the current choice and I haven't seen any clear problem with it yet, so I'd tend to lean towards keeping the current behavior. What would be the concrete advantages of the new behavior compared to the current one? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 08 11:33:41 2023 Received: (at 65051) by debbugs.gnu.org; 8 Aug 2023 15:33:41 +0000 Received: from localhost ([127.0.0.1]:37553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTOiL-0001FQ-Cn for submit@debbugs.gnu.org; Tue, 08 Aug 2023 11:33:41 -0400 Received: from mx3.muc.de ([193.149.48.5]:57264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTOiJ-0001F3-MY for 65051@debbugs.gnu.org; Tue, 08 Aug 2023 11:33:40 -0400 Received: (qmail 35992 invoked by uid 3782); 8 Aug 2023 17:33:33 +0200 Received: from acm.muc.de (pd953ac8f.dip0.t-ipconnect.de [217.83.172.143]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 08 Aug 2023 17:33:32 +0200 Received: (qmail 7938 invoked by uid 1000); 8 Aug 2023 15:33:32 -0000 Date: Tue, 8 Aug 2023 15:33:32 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (-) Hello, Stefan. On Mon, Aug 07, 2023 at 22:56:31 -0400, Stefan Monnier wrote: > >> Could you explain why you think it's a bug? > > When symbols-with-pos-enabled is non-nil, the two arguments to that > > equal call are equal. That is the point of s-w-p-e. > AFAIK the point of the `symbols-with-pos-enabled` is to try and keep the > performance impact of sympos under control, and that matters only for > `eq`, so I don't think there's a strong reason here for `equal` to pay > attention to it. Which is like saying you're happy for it to be undefined. In the code at the moment, the result of `equal' on symbols with position is undefined, i.e. it returns a random value. > > When s-w-p-e is nil, and the "magic" is thus switched off, the two lisp > > objects have different type (the first is a symbol, the second is a > > pseudovector), thus cannot be equal. > "cannot" is obviously not the correct word here, since currently they > are considered `equal`, so clearly they *can* be considered `equal`: > it's easy to implement, and experience shows that "it works". > So I'm still wondering why you think it's a bug. Because it violates the definition and basic understanding of equal. It's a special case when no special case is needed. > AFAICT whether sympos should be `equal` to others and/or to bare symbols > is something we pretty much get to choose freely based on convenience: No we don't. They have to be chosen to be as consistent as possible with the rest of Emacs. > either the current behavior or the one you now advocate are perfectly > acceptable and not bugs. The current behaviour is a bug. It was me that coded up that amendment to equal, and I can remember simply not taking into account the scenario we're talking about. > As I said elsewhere, I'm not sure which choice is best, but at least we > have some experience with the current choice .... I rather doubt that. When have SWPs, when symbols-with-pos-enabled is nil, been tested by equal, apart from in tests, maybe? > .... and I haven't seen any clear problem with it yet, so I'd tend to > lean towards keeping the current behavior. I'm wondering why you're making such a big thing out of it. It's a small change which will increase consistency and predictability in Emacs in a small way, without any negative effects. > What would be the concrete advantages of the new behavior compared to > the current one? There are no "concrete" advantages, aside from an insignificant increase in speed for Emacs when not byte compiling. The code and the documentation currently don't match. Fixing the code, by removing a special case, is easier and more satisfying than documenting that special case in the Elisp manual. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 09 14:46:09 2023 Received: (at 65051) by debbugs.gnu.org; 9 Aug 2023 18:46:09 +0000 Received: from localhost ([127.0.0.1]:40507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qToC8-00058I-T8 for submit@debbugs.gnu.org; Wed, 09 Aug 2023 14:46:09 -0400 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:50589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qToC7-00057f-6M for 65051@debbugs.gnu.org; Wed, 09 Aug 2023 14:46:08 -0400 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4fe48a2801bso94030e87.1 for <65051@debbugs.gnu.org>; Wed, 09 Aug 2023 11:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691606761; x=1692211561; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=8B7/5eEbJXBAtbY32qZ/x6HOSxpLnJElO3uQfNUJdrY=; b=InXDivvovbuEW/fvmonQ3tse+M1z5TZtD3mFMtq2HB+RHRpHewHc5mZB12/YeHQf49 kuMXo8H6P3+F8M0dg0zCruJpGkN1XnDXA4eztyMBKkf7MjZHArpRJHTvjrzutM6OngiS 37DkmFVIXpBAZ7dZJC/fcyBXEdexIPz4X68sthF1Fk1XvAxVywtzJWmtZMgCrtfUAwVn /50n/7NOVwf5+wRjktRp6BBRZu3PZ4DqK/QVf6AVTvlrDlJxTQAahIfKWd2CEnLRbhhC eEXTWKsOpD4JZ1ae4bdkSnBrbApngDPuFyqqfk2XzZKEEUU984f+ydXS4dC2HlCPNhqJ RGdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691606761; x=1692211561; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=8B7/5eEbJXBAtbY32qZ/x6HOSxpLnJElO3uQfNUJdrY=; b=WIBu2c6wfLFz108M40ZsQ5wSEjaRlcg97Z2NZWPnZ/hoGtwKOp/lyP4EzDgNYYN+x/ gh+frjDGkOIGxtTGX2xs4E42pvnLSQxFii8DjToJEH235Yr6e3XobqEd8AjdH+s2VA43 TOkpuQtTOPiB2S7S38HBVq++v5aoN5z4tXwIj11pw1gLUQumwotg7e3M3xnTb3eK/qjR z/4uy5TiOfQLl5gd3+Ntn/3CwZ+ZOFvxu3PtKB5fimkz8hKE/OitO7GdL/WKS2irN/2w ovR/xC8hJ8pCmgdV1FUNYyFzmtreoCJ7VZiH2IKu3yLcCp5sx/46sjC7UHYARIi38z60 TPEg== X-Gm-Message-State: AOJu0YwWTsgp2acXury4kmCC37Viqf0ZJB8LrQvrP5ghCaG36/Ujfy/P I6XNcWHtBSln+iZ9S4SHcW0= X-Google-Smtp-Source: AGHT+IEIX2ISNP2iWEl3fvh2iEbqZOYd5rKihigQvxq7ecOfNyodM4O2btvMFml0EaruMlmW5KP8mg== X-Received: by 2002:a19:8c06:0:b0:4fe:2ac1:4151 with SMTP id o6-20020a198c06000000b004fe2ac14151mr2251022lfd.63.1691606760851; Wed, 09 Aug 2023 11:46:00 -0700 (PDT) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id y3-20020ac24463000000b004fddddcf5e7sm2409768lfl.91.2023.08.09.11.45.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2023 11:45:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Wed, 9 Aug 2023 20:45:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B511686-67B7-40A3-971A-E5089B1D9A18@gmail.com> References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> <65A42652-DB4A-4FA6-8ADA-0D5BEB00F54C@gmail.com> To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, Eli Zaretskii , 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: -1.0 (-) 7 aug. 2023 kl. 11.44 skrev Alan Mackenzie : >> Oh that part is perfectly fine (thank you), we just don't need to say >> that the sympos objects are stored "like vectors" -- that just = confuses >> the reader. >=20 > Why not? It's true, and I doubt it will cause confusion. I think we > need to say something positive in that place (since we're following it > with a negative). Perhaps you could suggest an alternative. What I meant is that sympos objects are not at all like vectors in that = they aren't mutable, indexable, readable, they can't be used with = aref/aset, can't hold arbitrary values, don't form sequences, and so on, = so it makes sense that we try finding another description. What about = some variation on: A @dfn{symbol with position} is an immutable object consisting of a @dfn{bare symbol} and a position, a natural number. (You can probably do better.) >> I meant that the components of equal sympos objects aren't merely = equal >> but identical. (This is a very minor quibble; you can keep the text = if >> you like.) >=20 > The current proposed text has a more subtle intention. It says that = eq > and equal behave just like they always have done for everything when > symbols-with-pos-enabled is nil. No, I just meant that the components themselves in equal sympos objects = are eq, not just equal. But this isn't important. >> If the compiler transforms (eq foo1 foo1) into t then the test won't >> actually exercise the implementation of `eq`. >=20 > Ah! You're talking about the tests. OK. In my tests, I timed (equal = a > b) where a and b were variables which were either equal or not. As a matter of fact I went ahead and added the aforementioned = optimisation. It is something I had wanted to do for quite some time = because code like (eq VAR VAR) does occur from time to time from = macro-expansion etc. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 09 23:29:11 2023 Received: (at 65051) by debbugs.gnu.org; 10 Aug 2023 03:29:11 +0000 Received: from localhost ([127.0.0.1]:40920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTwMI-0004qD-Vt for submit@debbugs.gnu.org; Wed, 09 Aug 2023 23:29:11 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTwMG-0004py-J8 for 65051@debbugs.gnu.org; Wed, 09 Aug 2023 23:29:09 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C6F1B444DB9; Wed, 9 Aug 2023 23:29:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691638140; bh=JZyIeilVTx5ZY1uBjZPvG0WqM9LiRrPlROWL32JZMuc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Jbtv9qihdCRBLgOn1jnR7cdXVpp4Cz42tR9qP+8rt8jfX83ww0vAcNHVrCyHWxzDA 9+03SdUPzLOQ2ERq2acK0TQcmY365IKar7JlDXcFOb7sVqnKN+TM6d8krZz65pCuHL HtYsecXoANx5C57x/S+DGAYBeNNfY5LdRqkcuuT2U2zvYGdXnn4PCZgl3A/yUf8If4 pdOCUhKScWGtAapejgB8t1VHNfizGepG6DHU1c7XKJxvfOW1EHCK4zcnQ64PxJ0M4X azdRLwO5+Y9sf4Muhh4ZXqoCbKvg5e8248iLnzLA1GpRwGOlE12Q+uwfkMg3Eq+Hf7 HP8Wo1R+lRObg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E23A3444DB5; Wed, 9 Aug 2023 23:29:00 -0400 (EDT) Received: from alfajor (unknown [190.190.107.145]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 047631201A7; Wed, 9 Aug 2023 23:28:59 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: (Alan Mackenzie's message of "Tue, 8 Aug 2023 15:33:32 +0000") Message-ID: References: Date: Wed, 09 Aug 2023 23:28:53 -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 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-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) >> >> Could you explain why you think it's a bug? >> > When symbols-with-pos-enabled is non-nil, the two arguments to that >> > equal call are equal. That is the point of s-w-p-e. >> AFAIK the point of the `symbols-with-pos-enabled` is to try and keep the >> performance impact of sympos under control, and that matters only for >> `eq`, so I don't think there's a strong reason here for `equal` to pay >> attention to it. > Which is like saying you're happy for it to be undefined. Not quite. I'm saying that as far as technical reasons go, I can't see any reason why `equal` needs to pay attention to `symbols-with-pos-enabled`. IOW affecting the behavior of `equal` is *not* part of "the point of s-w-p-e". > In the code at the moment, the result of `equal' on symbols with > position is undefined, i.e. it returns a random value. In which sense? AFAICT it returns non-nil iff the underlying bare symbols are `eq`. That does not sound "random" at all to me. What am I missing? >> So I'm still wondering why you think it's a bug. > Because it violates the definition and basic understanding of equal. Could you expand on that, e.g. explaining which part of your understanding of "the definition and basic understanding of equal" it violates? > It's a special case when no special case is needed. Making `equal` depend on a global variable is also introducing a special case. IOW, all choices suck in one way or another. I think we need more practical and concrete reasons to prefer one over another. Philosophical arguments seem rather weak here. >> AFAICT whether sympos should be `equal` to others and/or to bare symbols >> is something we pretty much get to choose freely based on convenience: > No we don't. They have to be chosen to be as consistent as possible > with the rest of Emacs. `equal` is not self-consistent. It compares hash-tables like `eq` but looks inside vectors. It ignores strings' properties. The list goes on and on. >> either the current behavior or the one you now advocate are perfectly >> acceptable and not bugs. > The current behaviour is a bug. Hmm... This subthread is supposed to answer my question about why you think it's a bug. So just re-stating it is not very helpful. Please try and articulate more precisely *why* you think it's the case. Is it a gut-feeling? > It was me that coded up that amendment to equal, and I can remember > simply not taking into account the scenario we're talking about. Which scenario? >> As I said elsewhere, I'm not sure which choice is best, but at least we >> have some experience with the current choice .... > I rather doubt that. When have SWPs, when symbols-with-pos-enabled is > nil, been tested by equal, apart from in tests, maybe? We don't know, admittedly, but we do know that if/when it has happened, it hasn't caused any problem so far. >> .... and I haven't seen any clear problem with it yet, so I'd tend to >> lean towards keeping the current behavior. > I'm wondering why you're making such a big thing out of it. It's a > small change which will increase consistency and predictability in > Emacs in a small way, without any negative effects. I don't see either of the two options as being more consistent or more predictable. You can see symbols' positions as being similar to strings' properties, which `equal` gleefully ignores. I think the main reasons I'm rather opposed are: - I don't like making `equal` depend on a global variable. It makes it impure, and will invalidate existing optimizations, exactly like we've just witnessed for `eq`. - I consider `symbols-with-pos-enabled` to be a wart, so I'd rather try and minimize its use as much as possible. >> What would be the concrete advantages of the new behavior compared to >> the current one? > There are no "concrete" advantages, aside from an insignificant increase > in speed for Emacs when not byte compiling. The code and the > documentation currently don't match. Fixing the code, by removing a > special case, is easier and more satisfying than documenting that > special case in the Elisp manual. Then, I'd vote to fix the doc rather than the code. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 05:14:45 2023 Received: (at 65051) by debbugs.gnu.org; 10 Aug 2023 09:14:45 +0000 Received: from localhost ([127.0.0.1]:41366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU1ki-00068M-EK for submit@debbugs.gnu.org; Thu, 10 Aug 2023 05:14:44 -0400 Received: from mx3.muc.de ([193.149.48.5]:18364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU1kg-000687-0a for 65051@debbugs.gnu.org; Thu, 10 Aug 2023 05:14:42 -0400 Received: (qmail 12195 invoked by uid 3782); 10 Aug 2023 11:14:34 +0200 Received: from acm.muc.de (pd953a568.dip0.t-ipconnect.de [217.83.165.104]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Aug 2023 11:14:34 +0200 Received: (qmail 17548 invoked by uid 1000); 10 Aug 2023 09:14:33 -0000 Date: Thu, 10 Aug 2023 09:14:33 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (-) Hello, Stefan. On Wed, Aug 09, 2023 at 23:28:53 -0400, Stefan Monnier wrote: > >> >> Could you explain why you think it's a bug? > >> > When symbols-with-pos-enabled is non-nil, the two arguments to that > >> > equal call are equal. That is the point of s-w-p-e. > >> AFAIK the point of the `symbols-with-pos-enabled` is to try and keep the > >> performance impact of sympos under control, and that matters only for > >> `eq`, so I don't think there's a strong reason here for `equal` to pay > >> attention to it. > > Which is like saying you're happy for it to be undefined. > Not quite. I'm saying that as far as technical reasons go, I can't see > any reason why `equal` needs to pay attention to > `symbols-with-pos-enabled`. I can. > IOW affecting the behavior of `equal` is *not* part of "the point of > s-w-p-e". Which is precisely why I want to correct the behaviour of equal with SWPs. > > In the code at the moment, the result of `equal' on symbols with > > position is undefined, i.e. it returns a random value. > In which sense? In the sense it wasn't deliberately coded. It's just a random value resulting from the code for other scenarios. > AFAICT it returns non-nil iff the underlying bare symbols are `eq`. > That does not sound "random" at all to me. > What am I missing? That equal is different from eq. The definition of eq (more or less) is "identical objects". The definition of equal (more or less) is "same structure with same components". > >> So I'm still wondering why you think it's a bug. > > Because it violates the definition and basic understanding of equal. > Could you expand on that, e.g. explaining which part of your > understanding of "the definition and basic understanding of equal" > it violates? See my previous paragraph of this post. You're proposing that the position elements of SWPs should be ignored in equal. I don't see any good reason for this. > > It's a special case when no special case is needed. > Making `equal` depend on a global variable is also introducing > a special case. I know you don't like symbols-with-pos-enabled, but it's there. It implements, by its very nature, special cases when it's non-nil. You want to extend those special cases to the behaviour when it's nil. > IOW, all choices suck in one way or another. Not really. > I think we need more practical and concrete reasons to prefer one over > another. Philosophical arguments seem rather weak here. The consistency of Emacs's basic functions seems very important to me, and it's likely very important to other people, too. You seem to be dismissing it as unimportant. > >> AFAICT whether sympos should be `equal` to others and/or to bare symbols > >> is something we pretty much get to choose freely based on convenience: > > No we don't. They have to be chosen to be as consistent as possible > > with the rest of Emacs. > `equal` is not self-consistent. It compares hash-tables like `eq` but > looks inside vectors. It ignores strings' properties. The list goes on > and on. I said "as consistent as possible", not "absolutely consistent". There is no need to make that list of inconsistencies any bigger. > >> either the current behavior or the one you now advocate are perfectly > >> acceptable and not bugs. > > The current behaviour is a bug. > Hmm... This subthread is supposed to answer my question about why you > think it's a bug. So just re-stating it is not very helpful. > Please try and articulate more precisely *why* you think it's the case. > Is it a gut-feeling? I've outlined several times why it's a bug. Please re-read my posts in this thread. > > It was me that coded up that amendment to equal, and I can remember > > simply not taking into account the scenario we're talking about. > Which scenario? Comparing two arguments using equal, at least one of which is a symbol with position, when symbols-with-pos-enabled is nil. > >> As I said elsewhere, I'm not sure which choice is best, but at least we > >> have some experience with the current choice .... > > I rather doubt that. When have SWPs, when symbols-with-pos-enabled is > > nil, been tested by equal, apart from in tests, maybe? > We don't know, admittedly, but we do know that if/when it has happened, > it hasn't caused any problem so far. Just like binding symbols-with-position-enabled in internal-macroexpand-for-load didn't cause any problems, until it did (bug #65017). > >> .... and I haven't seen any clear problem with it yet, so I'd tend to > >> lean towards keeping the current behavior. > > I'm wondering why you're making such a big thing out of it. It's a > > small change which will increase consistency and predictability in > > Emacs in a small way, without any negative effects. > I don't see either of the two options as being more consistent or > more predictable. So why are you making such a big thing out of it? I see quite clearly which of these options is correct. Why won't you respect my superior insight into the matter? > You can see symbols' positions as being similar to strings' > properties, which `equal` gleefully ignores. > I think the main reasons I'm rather opposed are: > - I don't like making `equal` depend on a global variable. You prefer to make the effect of equal inconsistent. > It makes it impure, and will invalidate existing optimizations, > exactly like we've just witnessed for `eq`. Which optimisations are you talking about here? Just how is equal optimised? The function internal_equal will be called in all cases, apart from, perhaps, when called with identical arguments. > - I consider `symbols-with-pos-enabled` to be a wart, so I'd rather try > and minimize its use as much as possible. Why do you want to minimise its use, wart or not? Do you not care about its consistency? > >> What would be the concrete advantages of the new behavior compared to > >> the current one? > > There are no "concrete" advantages, aside from an insignificant increase > > in speed for Emacs when not byte compiling. The code and the > > documentation currently don't match. Fixing the code, by removing a > > special case, is easier and more satisfying than documenting that > > special case in the Elisp manual. > Then, I'd vote to fix the doc rather than the code. Write a proposed patch to the doc, then, and post it in this thread. At this stage, I feel I must point out that arguing with you on this mailing list about this point has taken up more time that fixing the code and documentation did. That is not a good thing. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 10:29:16 2023 Received: (at 65051) by debbugs.gnu.org; 10 Aug 2023 14:29:16 +0000 Received: from localhost ([127.0.0.1]:43810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU6f6-0006MU-3R for submit@debbugs.gnu.org; Thu, 10 Aug 2023 10:29:16 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU6f0-0006MB-SN for 65051@debbugs.gnu.org; Thu, 10 Aug 2023 10:29:14 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 118BF1000AD; Thu, 10 Aug 2023 10:29:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691677739; bh=ZxPzUopqBShhEv3bAJSOeuozfeRZwFH+Sz+JXQSxVuY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TaBTvRpVoTdr14sNejINXW7cektktG0FuZ65p88ne2Fqllvy1LdHBvOHVOrJ2M3P1 GMHYhPLtOEJdHRCsgQLabfMZOKlf50WUwV0LB/msOvKm7n7kB6RG8J8Vf2CA0Twty4 k96ltz5mU6UpqOvQIIZ5jrZ+zXjC7VUKEV3yzqnV27rPXYju60jb5RqSqgvpiBg5SE q3qdYtd9tyrtzgqmFK6cL/Qok19wYUCE+QOoQ4q09a9FCRKOWsGegDkZ9O1bJT9P6h y2Hf3PdV0MUdVog8Ahjcp4DggE8xzxUOc0rWw2laMAIDV+uZeS4jo0jlFTJt6xSGZu WIDMAodUaEIgw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7CC6510006B; Thu, 10 Aug 2023 10:28:59 -0400 (EDT) Received: from alfajor (unknown [190.190.107.145]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A5446120203; Thu, 10 Aug 2023 10:28:58 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: (Alan Mackenzie's message of "Thu, 10 Aug 2023 09:14:33 +0000") Message-ID: References: Date: Thu, 10 Aug 2023 10:28:55 -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 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-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) >> IOW affecting the behavior of `equal` is *not* part of "the point of >> s-w-p-e". > Which is precisely why I want to correct the behaviour of equal with > SWPs. I can't see the connection between the two. >> > In the code at the moment, the result of `equal' on symbols with >> > position is undefined, i.e. it returns a random value. >> In which sense? > In the sense it wasn't deliberately coded. It's just a random value > resulting from the code for other scenarios. Then it's not "random" nor "undefined". I'd describe it as "arbitrary". >> AFAICT it returns non-nil iff the underlying bare symbols are `eq`. >> That does not sound "random" at all to me. >> What am I missing? > That equal is different from eq. Then let me rephrase the above: AFAICT it returns non-nil iff the underlying bare symbols are `equal`. See? No` eq` any more :-) > The definition of eq (more or less) is "identical objects". > The definition of equal (more or less) is "same structure with same > components". Yes, but the "more or less" is very applicable to SWP. E.g. one could argue that if two objects are sometimes `eq`, then I think it's a good enough justification to treat them as always `equal`. > See my previous paragraph of this post. You're proposing that the > position elements of SWPs should be ignored in equal. I don't see any > good reason for this. One reason is that it's the semantics we use 99% of the time (where `symbols-with-pos-enabled` is also non-nil). But as I said at the beginning, my main point is that the current behavior is not a *bug*. It's just an arbitrary semantics, and you're proposing to use another arbitrary semantics. And the new arbitrary semantics does not seem clearly superior. IOW, bikeshedding material. >> > It's a special case when no special case is needed. >> Making `equal` depend on a global variable is also introducing >> a special case. > I know you don't like symbols-with-pos-enabled, but it's there. > It implements, by its very nature, special cases when it's non-nil. > You want to extend those special cases to the behaviour when it's nil. I'd say it's a biased way to look at it. For `eq` the semantics provided by `symbols-with-pos-enabled` is definitely very special because it is fundamentally incompatible with the usual promise of `eq` which is that when two objects are `eq` you can't distinguish them at all. But the behavior for `equal` is not "special" IMO. It fits within the general behavior of `equal`. > The consistency of Emacs's basic functions seems very important to me, > and it's likely very important to other people, too. You seem to be > dismissing it as unimportant. No, I don't dismiss the importance of consistency in general. I just think here both behaviors are about equally consistent with the general behavior of `equal`. So consistency is not a good guideline because it's based on nothing more than opinions. > I've outlined several times why it's a bug. That has not come through, I'm afraid. All I've seen so far are repetitions that you think the current behavior is inconsistent/undefined/random. None of it is concrete, and I disagree with them, so it's just my opinion against your opinion. We're not going to have much success with that. Hence the need for more concrete practical arguments. >> > It was me that coded up that amendment to equal, and I can remember >> > simply not taking into account the scenario we're talking about. >> Which scenario? > Comparing two arguments using equal, at least one of which is a > symbol with position, when symbols-with-pos-enabled is nil. Ah, sorry, I thought you were referring to a more concrete use-case where such a `equal` test would occur. Having such use-cases would help the current discussion significantly, since currently we're basically arguing about what Emacs should do in cases that never occur. >> We don't know, admittedly, but we do know that if/when it has happened, >> it hasn't caused any problem so far. > Just like binding symbols-with-position-enabled in > internal-macroexpand-for-load didn't cause any problems, until it did > (bug #65017). We don't know that. Maybe the new behavior would be the one that introduces such bugs. Or maybe both. Or neither. We just have no idea. > So why are you making such a big thing out of it? [ Hmm... I have a feeling of d=E9j=E0-vu. ] > I see quite clearly which of these options is correct. > Why won't you respect my superior insight into the matter? [ Hmm... this sounds a bit arrogant, so I'll just skip it. ] >> It makes it impure, and will invalidate existing optimizations, >> exactly like we've just witnessed for `eq`. > Which optimisations are you talking about here? Just how is equal > optimised? The same one that causes my bug-fix to fail: (let ((symbols-with-position-enabled V)) (equal E1 E2)) is optimized to (equal E1 E2) -- Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 14:35:39 2023 Received: (at 65051) by debbugs.gnu.org; 10 Aug 2023 18:35:39 +0000 Received: from localhost ([127.0.0.1]:44105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUAVW-0004cT-MC for submit@debbugs.gnu.org; Thu, 10 Aug 2023 14:35:39 -0400 Received: from mx3.muc.de ([193.149.48.5]:34176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUAVS-0004c7-Ta for 65051@debbugs.gnu.org; Thu, 10 Aug 2023 14:35:37 -0400 Received: (qmail 63652 invoked by uid 3782); 10 Aug 2023 20:35:28 +0200 Received: from acm.muc.de (pd953a568.dip0.t-ipconnect.de [217.83.165.104]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Aug 2023 20:35:28 +0200 Received: (qmail 7363 invoked by uid 1000); 10 Aug 2023 18:35:27 -0000 Date: Thu, 10 Aug 2023 18:35:27 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (-) Hello, Stefan. On Thu, Aug 10, 2023 at 10:28:55 -0400, Stefan Monnier wrote: [ .... ] > >> > In the code at the moment, the result of `equal' on symbols with > >> > position is undefined, i.e. it returns a random value. > >> In which sense? > > In the sense it wasn't deliberately coded. It's just a random value > > resulting from the code for other scenarios. > Then it's not "random" nor "undefined". > I'd describe it as "arbitrary". Then we're reduced to arguing about words rather than Emacs. > >> AFAICT it returns non-nil iff the underlying bare symbols are `eq`. > >> That does not sound "random" at all to me. > >> What am I missing? > > That equal is different from eq. > Then let me rephrase the above: > AFAICT it returns non-nil iff the underlying bare symbols are `equal`. > See? No` eq` any more :-) Yes I see, and it is wrong. Let me try another tack. Look closely at the definition of symbols-with-pos-enabled: (i) When nil: Emacs works without any special handling for SWPs. (ii) When non-nil: Emacs handles SWPs as though they were their bare symbols. > > The definition of eq (more or less) is "identical objects". > > The definition of equal (more or less) is "same structure with same > > components". > Yes, but the "more or less" is very applicable to SWP. > E.g. one could argue that if two objects are sometimes `eq`, then > I think it's a good enough justification to treat them as always > `equal`. A SWP is sometimes EQ its bare symbol, in particular when symbols-with-pos-enabled is non-nil. That is no justification for regarding the two as _always_ EQ, in particular when s-w-p-enabled is nil. If you were to make that argument, you would be arguing for a significant slowdown in Emacs. > > See my previous paragraph of this post. You're proposing that the > > position elements of SWPs should be ignored in equal. I don't see any > > good reason for this. > One reason is that it's the semantics we use 99% of the time (where > `symbols-with-pos-enabled` is also non-nil). It's not the semantics we should use when s-w-p-enabled is nil. That would violate the definition of symbols-with-pos-enabled. See above. > But as I said at the beginning, my main point is that the current > behavior is not a *bug*. It's just an arbitrary semantics, and you're > proposing to use another arbitrary semantics. I'm proposing correctness, according to a coherent definition of symbols-with-pos-enabled. I was surprised indeed, and continue to be surprised, that you do not see this correction as a correction. To me, it's obvious. > And the new arbitrary semantics does not seem clearly superior. > IOW, bikeshedding material. The correctness of symbols-with-pos-enabled is not arbitrary. If you think the semantics are arbitrary, why are you so fixed on implementing a particular one of them? [ .... ] > But the behavior for `equal` is not "special" IMO. It fits within the > general behavior of `equal`. Yet you're insisting on special behaviour for SWP's when symbols-with-pos-enabled is nil. [ .... ] > None of it is concrete, and I disagree with them, so it's just my opinion > against your opinion. We're not going to have much success with that. > Hence the need for more concrete practical arguments. Well, one argument, not very strong but stronger than any other you'll accept is that the code and documentation amendments have already been made. There are so far no signs of the needed documentation changes for leaving the handling of SWPs by equal contrasting with that of other types. > >> > It was me that coded up that amendment to equal, and I can remember > >> > simply not taking into account the scenario we're talking about. > >> Which scenario? > > Comparing two arguments using equal, at least one of which is a > > symbol with position, when symbols-with-pos-enabled is nil. > Ah, sorry, I thought you were referring to a more concrete use-case > where such a `equal` test would occur. Having such use-cases would help > the current discussion significantly, since currently we're basically > arguing about what Emacs should do in cases that never occur. That is the case, yes. There are no current use-cases for SWPs with s-w-p-enabled nil. [ .... ] > > So why are you making such a big thing out of it? > [ Hmm... I have a feeling of déjà-vu. ] > > I see quite clearly which of these options is correct. > > Why won't you respect my superior insight into the matter? > [ Hmm... this sounds a bit arrogant, so I'll just skip it. ] No, you won't. There is a basic contradiction in your stance, namely you say on the one hand that the correct strategy here is arbitrary, yet on the other hand that the one you prefer is overwhelmingly better. If you were being honest about this arbitrariness, you wouldn't be making such a song and dance about it. > >> It makes it impure, and will invalidate existing optimizations, > >> exactly like we've just witnessed for `eq`. > > Which optimisations are you talking about here? Just how is equal > > optimised? > The same one that causes my bug-fix to fail: > (let ((symbols-with-position-enabled V)) (equal E1 E2)) > is optimized to > (equal E1 E2) What can I say? If you eliminate semantically essential code what you end up with is not what you started with. Is there actually an instance of the above code in the Emacs sources? In particular, one where symbols-with-position-enabled gets bound by a let, and the body of the let contains an equal (or member, or ...), but no uses of EQ? > -- Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 20:51:21 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 00:51:21 +0000 Received: from localhost ([127.0.0.1]:44323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUGN7-0007JK-7p for submit@debbugs.gnu.org; Thu, 10 Aug 2023 20:51:21 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:36461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUGN5-0007J6-2H for 65051@debbugs.gnu.org; Thu, 10 Aug 2023 20:51:19 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 96BC232006F5; Thu, 10 Aug 2023 20:51:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 10 Aug 2023 20:51:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691715072; x=1691801472; bh=OVu2/L3YQRsP7rLygW0ns1cJBp/rhWGBhuj 35f6DaW8=; b=VRj75RBWDur0XyD27c7iNNqVIdmsMSZcN+DbMZz6lYgQD8K6Qoc uCcbV9aQRM9paMApfW3++6l1xtGBTIuS32CjBoeAxC9pBUDOnDYZSpocQ0kkXwxI xVItGcY429krUs945p6pkILTaaRSlv9QtxgPNf49ZPEk5yGqG7TIi2vVCMPmAIwm 4MlylEaFH/S5vm38FDKyaUwCizTLv/KIapYpZZ3aEtrRl+0/Cxm4CAe+NHTinTU4 GMWqFVNW/iLfQrjHoiAajzDDoruXhtr5seokWJLekrL1c7Uh9aNDxICUUgV+rgo/ P26oFDZ8wstPxfQ73l1MT9XhQqAio3SnI4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691715072; x=1691801472; bh=OVu2/L3YQRsP7rLygW0ns1cJBp/rhWGBhuj 35f6DaW8=; b=d+ZvJ6kPmftRlMM+WkFxzfdtLXqdhgTjPM1+qqH3To7UjqB6Aq6 rtKKDi1tX1uwJAh/Yzp4djIjQKZNWwlBwXG0oXKyOKcaa5lq3NgVWc070xiaJMIZ uhOXHMbTsfO3zAZzuJtbQLH1PBMQKNTjL1opVymzDcNST557DhgKdCxC23Acdz0M oqMbpcggwKMNd9VDu7NcQ+TS9Qeyy9+jnVYp0c1aNSGRen98aUiKnNVxmR5jcMMK lPXmEalX74tQIQbODw8A8YmjNUOetT1GnQEydCCBsV2DbgeQscbERi/huPfYjiX5 7qxeQmbUVKOFLjOEHYOqIYqIb4T+/0drYag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleejgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Aug 2023 20:51:10 -0400 (EDT) Message-ID: Date: Fri, 11 Aug 2023 03:51:09 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Content-Language: en-US To: Alan Mackenzie , Stefan Monnier References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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.8 (-) On 08/08/2023 18:33, Alan Mackenzie wrote: >> So I'm still wondering why you think it's a bug. > Because it violates the definition and basic understanding of equal. > It's a special case when no special case is needed. > Does 'equal'-ity of strings with and without text properties (or with different text properties) violate these as well? From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 06:42:25 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 10:42:25 +0000 Received: from localhost ([127.0.0.1]:44994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUPb6-0000Az-Ob for submit@debbugs.gnu.org; Fri, 11 Aug 2023 06:42:24 -0400 Received: from mx3.muc.de ([193.149.48.5]:61233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUPb0-0000Ag-8X for 65051@debbugs.gnu.org; Fri, 11 Aug 2023 06:42:22 -0400 Received: (qmail 78689 invoked by uid 3782); 11 Aug 2023 12:42:11 +0200 Received: from acm.muc.de (p4fe151b9.dip0.t-ipconnect.de [79.225.81.185]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Aug 2023 12:42:10 +0200 Received: (qmail 4848 invoked by uid 1000); 11 Aug 2023 10:42:10 -0000 Date: Fri, 11 Aug 2023 10:42:10 +0000 To: Dmitry Gutov Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -1.0 (-) Hello, Dmitry. On Fri, Aug 11, 2023 at 03:51:09 +0300, Dmitry Gutov wrote: > On 08/08/2023 18:33, Alan Mackenzie wrote: > >> So I'm still wondering why you think it's a bug. > > Because it violates the definition and basic understanding of equal. > > It's a special case when no special case is needed. > Does 'equal'-ity of strings with and without text properties (or with > different text properties) violate these as well? Maybe, maybe not. It depends on whether you consider the text properties on a string (or buffer portion) an essential part of the string or not. I think it was possibly a design error to have text properties conceptually as a part of a string/buffer rather than something associated with it, like an overlay. The fact that equal ignores these properties supports this view. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 07:18:32 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 11:18:32 +0000 Received: from localhost ([127.0.0.1]:45055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUQA3-0001F4-PD for submit@debbugs.gnu.org; Fri, 11 Aug 2023 07:18:32 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:50329) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUQA0-0001En-78 for 65051@debbugs.gnu.org; Fri, 11 Aug 2023 07:18:30 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3045B32004ED; Fri, 11 Aug 2023 07:18:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 11 Aug 2023 07:18:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691752700; x=1691839100; bh=8od6tA8Ui7wL/C73XQMmx6wp5yANU/fbG7e eDZsNKlg=; b=D9l2DAz7O3M1Hru3VxS77guIX5sMwYLvNVAbPRQCGtWZxTEsKJV jkWwbV73d6DlrQoSfwTR8mtmdXRwKk4+2XIcI8MvR1V3IYrSRlYbD+UrTIQB+ikL fIbsJPsrFifxUim5zhmoGPZQ+MMDQQcIFpk+IUD4e6XFq8qhmN77E1wLXWGOwTSk 8bQNlYTAArgnI8UIWr1WoXSUNQNkJuw0/ytNvnK8if19GVfNHBVYuj+YjMyOFTMz bmLYPvXu44c4tiieqcuimQB0G22j6ZI1y1MtBN6DzJFRB5eIJeWHocYRhK7RZI+2 dgWXoRxRgaoPkVHWFJIAqyEdzIMR6pYrsEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691752700; x=1691839100; bh=8od6tA8Ui7wL/C73XQMmx6wp5yANU/fbG7e eDZsNKlg=; b=x8nY8fyQQNnb2zt/0pjLoKd+5c6OoCQBEHOilzVPWGJMgkTwjCV WngZq2t6hzizeOF7tf+QzSjSZ1ofvrYwV8YMvYccmO5nuHtLVfhBxevA5qoqHS4K BHLS/16X70PAIe+yYypqmHZWpJ3S1ZnLWdM6acnmE2R3RBrbY2pguC7LR4ACoyjt hFqB2hJJZpyONUnDBjbvcPQfz4ZBoIZIKJVKHaTzzfHSOXkzMeSQRIOjW/3hbFj+ uh7hxPjbEwGn8d+E5K+o/dx/OUfuLPTZsRqtRqcCamgnxaIUsa5CHJ71Q+yDk1dY IwUSOTK7WL5ehUwGe25vL9Eoq/vunhMZL8g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleekgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Aug 2023 07:18:18 -0400 (EDT) Message-ID: Date: Fri, 11 Aug 2023 14:18:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Content-Language: en-US To: Alan Mackenzie References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -1.8 (-) On 11/08/2023 13:42, Alan Mackenzie wrote: > Hello, Dmitry. > > On Fri, Aug 11, 2023 at 03:51:09 +0300, Dmitry Gutov wrote: >> On 08/08/2023 18:33, Alan Mackenzie wrote: >>>> So I'm still wondering why you think it's a bug. >>> Because it violates the definition and basic understanding of equal. >>> It's a special case when no special case is needed. > >> Does 'equal'-ity of strings with and without text properties (or with >> different text properties) violate these as well? > > Maybe, maybe not. It depends on whether you consider the text > properties on a string (or buffer portion) an essential part of the > string or not. ...or, like, a metadata attached to a value. Which is an approach to have its benefits as well, seeing how we've been living with it for many years. > I think it was possibly a design error to have text > properties conceptually as a part of a string/buffer rather than > something associated with it, like an overlay. The fact that equal > ignores these properties supports this view. We needed a reference to access the properties from. Overlays are different because they attach to a buffer. There is nothing else to attach to when you have a string value. Which seems very similar to the situation with symbols, I think. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 08:05:48 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 12:05:48 +0000 Received: from localhost ([127.0.0.1]:45108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUQto-0005AJ-3D for submit@debbugs.gnu.org; Fri, 11 Aug 2023 08:05:48 -0400 Received: from mx3.muc.de ([193.149.48.5]:63699) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUQti-00059y-BN for 65051@debbugs.gnu.org; Fri, 11 Aug 2023 08:05:46 -0400 Received: (qmail 75375 invoked by uid 3782); 11 Aug 2023 14:05:35 +0200 Received: from acm.muc.de (p4fe151b9.dip0.t-ipconnect.de [79.225.81.185]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Aug 2023 14:05:35 +0200 Received: (qmail 6548 invoked by uid 1000); 11 Aug 2023 12:05:34 -0000 Date: Fri, 11 Aug 2023 12:05:34 +0000 To: Dmitry Gutov Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -1.0 (-) Hello, Dmitry. On Fri, Aug 11, 2023 at 14:18:15 +0300, Dmitry Gutov wrote: > On 11/08/2023 13:42, Alan Mackenzie wrote: > > On Fri, Aug 11, 2023 at 03:51:09 +0300, Dmitry Gutov wrote: > >> On 08/08/2023 18:33, Alan Mackenzie wrote: > >>>> So I'm still wondering why you think it's a bug. > >>> Because it violates the definition and basic understanding of equal. > >>> It's a special case when no special case is needed. > >> Does 'equal'-ity of strings with and without text properties (or with > >> different text properties) violate these as well? > > Maybe, maybe not. It depends on whether you consider the text > > properties on a string (or buffer portion) an essential part of the > > string or not. > ...or, like, a metadata attached to a value. Which is an approach to > have its benefits as well, seeing how we've been living with it for many > years. > > I think it was possibly a design error to have text > > properties conceptually as a part of a string/buffer rather than > > something associated with it, like an overlay. The fact that equal > > ignores these properties supports this view. > We needed a reference to access the properties from. Overlays are > different because they attach to a buffer. There is nothing else to > attach to when you have a string value. This is arbitrary; overlays _could_ have been made attachable to strings, in which case text properties need not have been. That would have prevented all the heart searching when considering equal with strings. > Which seems very similar to the situation with symbols, I think. There are practical differences. Having symbols with position simply handled as their bare symbols would slow down Emacs quite a lot. That's why we have symbols-with-pos-enabled. But you know that. Currently, the working of s-w-p-enabled is inconsistent, and should be fixed, which is what this bug is about. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 09:20:05 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 13:20:05 +0000 Received: from localhost ([127.0.0.1]:45159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUS3g-00076j-Ou for submit@debbugs.gnu.org; Fri, 11 Aug 2023 09:20:05 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:58389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUS3b-00075z-I0 for 65051@debbugs.gnu.org; Fri, 11 Aug 2023 09:20:02 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8EABE32008FC; Fri, 11 Aug 2023 09:19:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 11 Aug 2023 09:19:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691759992; x=1691846392; bh=CdYYcLlZU5DGyyTDYecqvMRxrhpdsg5E+GI imh3RyVQ=; b=iTPhQ1IFSDOfx+zjiuHzUG7BgEj1K1s6a+5OJIWV46PmUIh3cYB /YqYNs2Pc4JTtB7oOvPdM6q34tbo5jaU6jVXTj0ZdSpHvhiYl98U55vgTPaIAd4s jcRHCQs7h6+MSE6t7QDWbD5XLzB6QWklpuAL59yn8HX+LuXky8ZOwKB3n8TTqO+1 t74B2sKQ/y2wn36C3GxAl1LzVHqcABUwJlz9eSaVPc9aE3GM6UNZU4zNbEJV0HCn gHKXImawuscE77yyZ+SNmH6b7pX0W7irysWlVIieMJ2XQuR86s9oTSbsJjLQiIuo bL0QAz71r2sNdFZVulMkh3WcFvfXaDWTwzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691759992; x=1691846392; bh=CdYYcLlZU5DGyyTDYecqvMRxrhpdsg5E+GI imh3RyVQ=; b=Kz9jp7P9fBopwt3xQnIAT/Tzv40jZntNxmzIxGsVnRqKhsQCCCj zvMPaGYjG/PcML+kIuzYuA0iLAAsHfBGBcc3Zz3bJBig4BNm6Qs9QGiTPivd6Wfs gaT81HDyQOdYjqxP/hla4WmNUOXCePkVioJy5gh5XiEfyClIaFUscP0vWHaV9Rya rY3rcUVXxRpCOYRVwrJBgEy4ejtIQXs1LlV9C4nU9N/f7Q/NMOXcxO9Q0Eh5wQCh oOn8Cdmw8NrqJaDeaRDUrSoQtPaPtYUMLXhY8VC0uyCkVOdH6RaNSZRKpK8/SrK1 uk55cQp+Bdh/6FMVc8mQdrBXmqMkGotZuFw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleekgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Aug 2023 09:19:50 -0400 (EDT) Message-ID: <6a81c696-4e6a-ac24-6c66-7e2b541ed67a@gutov.dev> Date: Fri, 11 Aug 2023 16:19:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Content-Language: en-US To: Alan Mackenzie References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -2.8 (--) Hi again, Alan, On 11/08/2023 15:05, Alan Mackenzie wrote: >>> I think it was possibly a design error to have text >>> properties conceptually as a part of a string/buffer rather than >>> something associated with it, like an overlay. The fact that equal >>> ignores these properties supports this view. > >> We needed a reference to access the properties from. Overlays are >> different because they attach to a buffer. There is nothing else to >> attach to when you have a string value. > > This is arbitrary; overlays _could_ have been made attachable to > strings, in which case text properties need not have been. That would > have prevented all the heart searching when considering equal with > strings. Then we would have some "metadata" that's part of the value, and some that is not part of the value. How would we look those up, though? Through a global registry? equal-including-properties is useful enough, by the way. In the tests, at least. >> Which seems very similar to the situation with symbols, I think. > > There are practical differences. Having symbols with position simply > handled as their bare symbols would slow down Emacs quite a lot. That's > why we have symbols-with-pos-enabled. But you know that. Does the current impl of 'equal' create worse performance as well? That would be a good argument to change it. > Currently, > the working of s-w-p-enabled is inconsistent, and should be fixed, which > is what this bug is about. Inconsistent with what? If we're talking about the relation between EQUAL and EQ, objects that are EQ have to be EQUAL, but those that are EQUAL don't have to be EQ. Anyway, I'd like to offer a question from a different perspective: should two symbols-with-positions where the positions are different but the symbol is the same, be equal between each other? If yes (which is my reading of fns.c:2755), then it makes sense for them to be equal-able to symbols without positions as well. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 10:05:11 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 14:05:11 +0000 Received: from localhost ([127.0.0.1]:47235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUSlL-0000U1-F7 for submit@debbugs.gnu.org; Fri, 11 Aug 2023 10:05:11 -0400 Received: from mx3.muc.de ([193.149.48.5]:11732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUSlH-0000TM-2R for 65051@debbugs.gnu.org; Fri, 11 Aug 2023 10:05:10 -0400 Received: (qmail 11545 invoked by uid 3782); 11 Aug 2023 16:05:00 +0200 Received: from acm.muc.de (p4fe151b9.dip0.t-ipconnect.de [79.225.81.185]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Aug 2023 16:04:59 +0200 Received: (qmail 7652 invoked by uid 1000); 11 Aug 2023 14:04:59 -0000 Date: Fri, 11 Aug 2023 14:04:59 +0000 To: Dmitry Gutov Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <6a81c696-4e6a-ac24-6c66-7e2b541ed67a@gutov.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a81c696-4e6a-ac24-6c66-7e2b541ed67a@gutov.dev> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -1.0 (-) Hello, Dmitry. On Fri, Aug 11, 2023 at 16:19:47 +0300, Dmitry Gutov wrote: > Hi again, Alan, > On 11/08/2023 15:05, Alan Mackenzie wrote: > >>> I think it was possibly a design error to have text > >>> properties conceptually as a part of a string/buffer rather than > >>> something associated with it, like an overlay. The fact that equal > >>> ignores these properties supports this view. > >> We needed a reference to access the properties from. Overlays are > >> different because they attach to a buffer. There is nothing else to > >> attach to when you have a string value. > > This is arbitrary; overlays _could_ have been made attachable to > > strings, in which case text properties need not have been. That would > > have prevented all the heart searching when considering equal with > > strings. > Then we would have some "metadata" that's part of the value, and some > that is not part of the value. How would we look those up, though? > Through a global registry? > equal-including-properties is useful enough, by the way. In the tests, > at least. Yes. > >> Which seems very similar to the situation with symbols, I think. > > There are practical differences. Having symbols with position simply > > handled as their bare symbols would slow down Emacs quite a lot. That's > > why we have symbols-with-pos-enabled. But you know that. > Does the current impl of 'equal' create worse performance as well? That > would be a good argument to change it. Yes, but unmeasurably so. The current implementation has two comparisons, quite complicated, where only one simple one is needed, for the typical use-case. > > Currently, the working of s-w-p-enabled is inconsistent, and > > should be fixed, which is what this bug is about. > Inconsistent with what? With its definition: when s-w-p-enabled is non-nil, SWPs are handled specially. When it's nil, they're not (or, at least, shouldn't be). > If we're talking about the relation between EQUAL and EQ, objects that > are EQ have to be EQUAL, but those that are EQUAL don't have to be EQ. I wasn't talking about that relationship, no, but there is no danger to it in fixing the current bug (or, indeed, in leaving it unfixed). > Anyway, I'd like to offer a question from a different perspective: > should two symbols-with-positions where the positions are different but > the symbol is the same, be equal between each other? Yes, when and only when symbols-with-pos-enabled is non-nil. > If yes (which is my reading of fns.c:2755), then it makes sense for > them to be equal-able to symbols without positions as well. Again, this should be the case when s-w-p-enabled is non-nil and only then. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 14:15:24 2023 Received: (at 65051) by debbugs.gnu.org; 11 Aug 2023 18:15:24 +0000 Received: from localhost ([127.0.0.1]:47943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUWfU-0006tZ-4R for submit@debbugs.gnu.org; Fri, 11 Aug 2023 14:15:24 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:33437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUWfR-0006tK-NL for 65051@debbugs.gnu.org; Fri, 11 Aug 2023 14:15:22 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A65285C0088; Fri, 11 Aug 2023 14:15:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 11 Aug 2023 14:15:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691777715; x=1691864115; bh=jBojgsLSQSvpBiKHx9TY369zES6gPWOvY2w 80oMLnME=; b=li3ksVEEobvoeRy6PiyxtadnJwsyd2invg+pARSJvEjb6e5bc9T NAYd1q4Ev19uvqN81SQYiPyoaBE7GzkOpxb/rrAmcT8uWlzF2Ox1cFeyxZX5KaRr h9DKww0XpnrKze1arDyW55Vkg6t9Xv9PHyIaXcviFvRtUGYFT7UVI7cPibClokVC JTnkQeEew8GkYx2f2CMm3mNjb1LQ6NTgInMcevjZwiJT1HUa4yqta2YeC7Vnr/li MPQFKPZDLLAQjfDfdY7tsAP3eTAnSaZbbUpfQDg7soU9+LOBMgAiefDzcQ2bg/mY y9t4o6Qx+HtShWA9+p47I/tnKb6HEpqFyTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691777715; x=1691864115; bh=jBojgsLSQSvpBiKHx9TY369zES6gPWOvY2w 80oMLnME=; b=nXuGx4KWiZhkNJQttje8VSn28Spv48MSYiKmX98D61yxisBMRqh txOSZII6smJPerdI4YIwDmH/TU7WApZzetqBkKyeKaBhnU5F7HyNbDwmZD4iLjKP gYtsBUvQFqYZqWD1+mrUF9h5MoYVeVJ7qLl9mh0EhCRVvylu7zBrCUBL7HgdR6c9 Q4zezIkGW/JKISSjp4sOyUbWY2zb86x5FtdmU0n9jAf2KP7GkRT5iOQtydzQjs9T 3AfYn8115u9br05RmYNL06Xul+mspzSeenvf9PLg91XC94WVMx8BtDGRv1SsInC4 Qk1STFyQD5GLHKNznPAX0S0SJbRkCqhBoPA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleekgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Aug 2023 14:15:14 -0400 (EDT) Message-ID: <8640914d-1f58-300c-da86-2ca6e214a513@gutov.dev> Date: Fri, 11 Aug 2023 21:15:12 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Content-Language: en-US To: Alan Mackenzie References: <6a81c696-4e6a-ac24-6c66-7e2b541ed67a@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, 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: -1.8 (-) Hi Alan, On 11/08/2023 17:04, Alan Mackenzie wrote: >> > Currently, the working of s-w-p-enabled is inconsistent, and >> > should be fixed, which is what this bug is about. > >> Inconsistent with what? > > With its definition: when s-w-p-enabled is non-nil, SWPs are handled > specially. When it's nil, they're not (or, at least, shouldn't be). Point taken. So either the behavior needs to be changed, or the docstring updated. >> If we're talking about the relation between EQUAL and EQ, objects that >> are EQ have to be EQUAL, but those that are EQUAL don't have to be EQ. > > I wasn't talking about that relationship, no, but there is no danger to > it in fixing the current bug (or, indeed, in leaving it unfixed). Yep. >> Anyway, I'd like to offer a question from a different perspective: >> should two symbols-with-positions where the positions are different but >> the symbol is the same, be equal between each other? > > Yes, when and only when symbols-with-pos-enabled is non-nil. > >> If yes (which is my reading of fns.c:2755), then it makes sense for >> them to be equal-able to symbols without positions as well. > > Again, this should be the case when s-w-p-enabled is non-nil and only > then. All right, that also makes sense. And I can see some theoretical benefit to not having these kinds of objects be 'equal' in contexts where that is not anticipated in advance (and so the variable is not bound). Especially in a stronger-typed language where such comparison or pattern matching could result in an error (e.g. comparing incompatible types). In our case, since we're just talking about 'equal', the comparison could result in execution just falling though and e.g. some bytecomp optimization not being applied, silently (hence the talk of "if not broken don't fix it"). It would be nice to see a piece of code that would benefit from the distinction. The reverse example I can imagine myself (some pcase form outside of any such binding, whether by accident or not). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 01:36:24 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 05:36:24 +0000 Received: from localhost ([127.0.0.1]:48431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUhIV-00012k-T4 for submit@debbugs.gnu.org; Sat, 12 Aug 2023 01:36:24 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUhIS-00012P-3X for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 01:36:22 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6CBB7100213; Sat, 12 Aug 2023 01:36:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691818568; bh=QNQXHQG83rpoK7tVBLl7kH9QEOsK2NGtHCCzHHckfBc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BVAj1GkabGS3vyvYnZz8LPvjlA4TRLkXRGOg/K5Nc50w1irVH3NplRtjOkcj3CNsA RSuMo4uzoBoP9g2C58zGdiAmhg73IfD0J/cwBR9mfOmE+THcox4CV1XF2mQZ3J+SsD wr7LbebCUKhMJ12zs4LMOs/sLDX16qNjHklvFl4myF8bZ5xt306/ZX4HCxMYFBSbKQ iG95nyeNdzQeQC55VddpAQOH9ZrbPmNAxNGkIWAuHge2qq5nLFNmc21/oTW4AYi1hb Toy/zivgLK2f5M/4KRooyHU6iY1W+wiJg7KdYNJNqLyYB9mGkH2LloKkpWE7rDENLe VWRYlWRv9dpzA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C2508100106; Sat, 12 Aug 2023 01:36:08 -0400 (EDT) Received: from pastel (69-165-141-248.dsl.teksavvy.com [69.165.141.248]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9D59F120394; Sat, 12 Aug 2023 01:36:08 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: (Alan Mackenzie's message of "Thu, 10 Aug 2023 18:35:27 +0000") Message-ID: References: Date: Sat, 12 Aug 2023 01:36:08 -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.897 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 KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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'm proposing correctness, according to a coherent definition of > symbols-with-pos-enabled. I was surprised indeed, and continue to be > surprised, that you do not see this correction as a correction. To me, > it's obvious. I guess it's because you see it as a feature that (symbol-function (position-symbol 'a 3)) signals an error when `symbols-with-pos-enabled` is nil, whereas I see it as a misfeature we should try and fix. > That is the case, yes. There are no current use-cases for SWPs with > s-w-p-enabled nil. Right. So all the code which behaves differently when encountering an SWP depending on the value of `s-w-p-enabled` has only one of the two branches tested. My preference for making the behavior oblivious to `s-w-p-enabled` (except for those rare cases where it's needed for performance reasons) removes these untested code paths. In any case, here's my "counter offer" (BTW, why we do handle SWP specially in `time-convert`?). Stefan diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi index 34db0caf3a8..0eb3e8f211d 100644 --- a/doc/lispref/symbols.texi +++ b/doc/lispref/symbols.texi @@ -782,11 +782,16 @@ Symbols with Position @cindex symbol with position @cindex bare symbol -A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, -together with an unsigned integer called the @dfn{position}. These -objects are intended for use by the byte compiler, which records in -them the position of each symbol occurrence and uses those positions -in warning and error messages. +A @dfn{symbol with position} is a pair of a symbol, the @dfn{bare symbol}, +together with an unsigned integer called the @dfn{position}. +They cannot themselves have entries in obarrays (contrary to their +bare symbols; @pxref{Creating Symbols}). + +Symbols with position are for the use of the byte compiler, which +records in them the position of each symbol occurrence and uses those +positions in warning and error messages. They shouldn't normally be +used otherwise. Doing so can cause unexpected results with basic +Emacs functions such as @code{eq} and @code{equal}. The printed representation of a symbol with position uses the hash notation outlined in @ref{Printed Representation}. It looks like @@ -798,11 +803,20 @@ Symbols with Position For most purposes, when the flag variable @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with -positions behave just as bare symbols do. For example, @samp{(eq -# foo)} has a value @code{t} when that variable -is set (but @code{nil} when it isn't set). Most of the time in Emacs this -variable is @code{nil}, but the byte compiler binds it to @code{t} -when it runs. +positions behave just as their bare symbols would. For example, +@samp{(eq # foo)} has a value @code{t} when the +variable is set; likewise, @code{equal} will treat a symbol with +position argument as its bare symbol. + +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with +position continue to exist, but do not always behave as symbols. +Most importantly @code{eq} only returns @code{t} when given truly +identical arguments, for performance reasons. @code{equal} on the +other hand is not affected, + +Most of the time in Emacs @code{symbols-with-pos-enabled} is +@code{nil}, but the byte compiler and the native compiler bind it to +@code{t} when they run. Typically, symbols with position are created by the byte compiler calling the reader function @code{read-positioning-symbols} diff --git a/src/fns.c b/src/fns.c index d7b2e7908b6..5239eb73026 100644 --- a/src/fns.c +++ b/src/fns.c @@ -5166,7 +5166,7 @@ sxhash_obj (Lisp_Object obj, int depth) hash = sxhash_combine (hash, sxhash_obj (XOVERLAY (obj)->plist, depth)); return SXHASH_REDUCE (hash); } - else if (symbols_with_pos_enabled && pvec_type == PVEC_SYMBOL_WITH_POS) + else if (pvec_type == PVEC_SYMBOL_WITH_POS) return sxhash_obj (XSYMBOL_WITH_POS (obj)->sym, depth + 1); else /* Others are 'equal' if they are 'eq', so take their diff --git a/src/timefns.c b/src/timefns.c index 151f5b482a3..7e030da3fcd 100644 --- a/src/timefns.c +++ b/src/timefns.c @@ -1767,8 +1767,6 @@ DEFUN ("time-convert", Ftime_convert, Stime_convert, 1, 2, 0, enum timeform input_form = decode_lisp_time (time, false, &t, 0); if (NILP (form)) form = current_time_list ? Qlist : Qt; - if (symbols_with_pos_enabled && SYMBOL_WITH_POS_P (form)) - form = SYMBOL_WITH_POS_SYM (form); if (BASE_EQ (form, Qlist)) return ticks_hz_list4 (t.ticks, t.hz); if (BASE_EQ (form, Qinteger)) From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 02:09:52 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 06:09:52 +0000 Received: from localhost ([127.0.0.1]:48466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUhou-0002H0-4A for submit@debbugs.gnu.org; Sat, 12 Aug 2023 02:09:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUhos-0002Gh-Ah for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 02:09:50 -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 1qUhom-0007fx-W8; Sat, 12 Aug 2023 02:09:45 -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=BBRldeWThFtyEioV4N5+4O82wNgQEUKS/aWlGQC5KJo=; b=i2jybs9WK4bB MR3PAlAfaRabxBpNr9OT2EjeE7IfgcjZ24GB9ai2ZUbpS7QVruepsgK5x8qQAFrFs9TARsR9LT8j4 6kUv14MYWrhsntbBDUdP0yN2AYIqnl1PdT7/VHrPYrZ7RRSaP8kT3378OdX23qzlIASGDXkSRpPoP 4yXtxjvEbuuMI/BSNw3PUXfrCK2PTEwkasRySGDDBQAHZuT/KbrIcmFWIHU3Wpm7ZTMFM6Cy0zygE 5JjxUfZo/WeazFAaTiHfp9SAXYOjOYg22vle7k/C/Whs7ELSgAyIwu607tIsxeUHoBDX+BuHSdVno ZcmJDxu2U1VKK1rPWgolqw==; Date: Sat, 12 Aug 2023 09:10:15 +0300 Message-Id: <83msywg5a0.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (---) > Cc: 65051@debbugs.gnu.org > Date: Sat, 12 Aug 2023 01:36:08 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > +A @dfn{symbol with position} is a pair of a symbol, the @dfn{bare symbol}, > +together with an unsigned integer called the @dfn{position}. > +They cannot themselves have entries in obarrays (contrary to their > +bare symbols; @pxref{Creating Symbols}). That "They" which begins the last sentence doesn't make clear who are "they". You want to say "Symbols with position" instead -- this is repetition, but in this case it is actually needed. > For most purposes, when the flag variable > @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with > -positions behave just as bare symbols do. For example, @samp{(eq > -# foo)} has a value @code{t} when that variable > -is set (but @code{nil} when it isn't set). Most of the time in Emacs this > -variable is @code{nil}, but the byte compiler binds it to @code{t} > -when it runs. > +positions behave just as their bare symbols would. For example, ^^^^^^^^^ "position", singular. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 06:41:33 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 10:41:33 +0000 Received: from localhost ([127.0.0.1]:48795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUm3p-0005MU-6T for submit@debbugs.gnu.org; Sat, 12 Aug 2023 06:41:33 -0400 Received: from mx3.muc.de ([193.149.48.5]:47528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUm3n-0005M5-HV for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 06:41:32 -0400 Received: (qmail 32769 invoked by uid 3782); 12 Aug 2023 12:41:25 +0200 Received: from acm.muc.de (p4fe1539a.dip0.t-ipconnect.de [79.225.83.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Aug 2023 12:41:24 +0200 Received: (qmail 9538 invoked by uid 1000); 12 Aug 2023 10:41:24 -0000 Date: Sat, 12 Aug 2023 10:41:24 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (-) Hello, Stefan. On Sat, Aug 12, 2023 at 01:36:08 -0400, Stefan Monnier wrote: [ .... ] > ..... (BTW, why we do handle SWP specially in `time-convert`?). That was this patch: commit 343482d641511b54aa0444791770b4ea70d27cc7 Author: Paul Eggert Date: Wed Jun 15 23:08:03 2022 -0500 Streamline time decoding and conversion * src/lisp.h (lisp_h_BASE2_EQ, BASE2_EQ): New macros and functions. * src/timefns.c (tzlookup, Fdecode_time): Use them. (Ftime_convert): Convert to symbol once, instead of many times. <===== .. form, if a SWP, gets replaced by its bare symbol, so that the following comparisons can be done by BASE_EQ rather than EQ. It's an optimisation, though I can't really see why it's worthwhile. If you remove that SWP handling, as you are proposing, you'll need to set these BASE_EQ's back to EQ's, too. > Stefan [ .... ] > diff --git a/src/timefns.c b/src/timefns.c > index 151f5b482a3..7e030da3fcd 100644 > --- a/src/timefns.c > +++ b/src/timefns.c > @@ -1767,8 +1767,6 @@ DEFUN ("time-convert", Ftime_convert, Stime_convert, 1, 2, 0, > enum timeform input_form = decode_lisp_time (time, false, &t, 0); > if (NILP (form)) > form = current_time_list ? Qlist : Qt; > - if (symbols_with_pos_enabled && SYMBOL_WITH_POS_P (form)) > - form = SYMBOL_WITH_POS_SYM (form); > if (BASE_EQ (form, Qlist)) > return ticks_hz_list4 (t.ticks, t.hz); > if (BASE_EQ (form, Qinteger)) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 14:07:54 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 18:07:54 +0000 Received: from localhost ([127.0.0.1]:57286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUt1m-0004AN-2l for submit@debbugs.gnu.org; Sat, 12 Aug 2023 14:07:54 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUt1k-0004A7-CZ for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 14:07:53 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 791C8441104; Sat, 12 Aug 2023 14:07:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691863665; bh=/NBYAonVjPJxvsgGXgZAy8nAKB9ubQywyN8LicV8+sQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U0JrUfYGa3uaLMx3i3bDGd5u76v1lzQkF1u4pkpULAgzDvCVlEr8Hutgs2Qdh5EhX xqgV2JE9vVAfc37gNLpMvCgz4Vcud53GwZLPbYsl3BegcXYzuDIgloH94tLhKi6Sc5 K+kOhrDJj3yEYHp16nKfSJKJwGc0js4n4IcsDUXw6SA2HJVRnRRbTcZgMlXT9zsbMG 4AAiBlu5Mf+YLxpQywfJcDjNECckNOL/lBbfKTA6SKzmqclv2VtJ+/ax0MMnTfWsck gjyU97S0jdhMwimFKaNSdx2i/r9XdtOR7eDEF/TiLYQ9CU/tBZcWkmZf4hOlOk/vqW fQtGJoUv300Sw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3E20A4410F3; Sat, 12 Aug 2023 14:07:45 -0400 (EDT) Received: from pastel (69-165-141-248.dsl.teksavvy.com [69.165.141.248]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1CC121200D7; Sat, 12 Aug 2023 14:07:45 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: (Alan Mackenzie's message of "Sat, 12 Aug 2023 10:41:24 +0000") Message-ID: References: Date: Sat, 12 Aug 2023 14:07:39 -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.151 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-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org 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 (---) > Streamline time decoding and conversion > > * src/lisp.h (lisp_h_BASE2_EQ, BASE2_EQ): New macros and functions. > * src/timefns.c (tzlookup, Fdecode_time): Use them. > (Ftime_convert): Convert to symbol once, instead of many times. <===== > > .. form, if a SWP, gets replaced by its bare symbol, so that the > following comparisons can be done by BASE_EQ rather than EQ. It's an > optimisation, though I can't really see why it's worthwhile. > > If you remove that SWP handling, as you are proposing, you'll need to > set these BASE_EQ's back to EQ's, too. I see, thanks. It's kind of odd, tho: it's the only function that does that, AFAICT. I also can't see why `time-convert` should accept SWPs in addition to bare symbols. In my book, it seems like passing it an SWP would be a mistake. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 14:46:36 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 18:46:37 +0000 Received: from localhost ([127.0.0.1]:57466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUtdE-0005Nd-Ex for submit@debbugs.gnu.org; Sat, 12 Aug 2023 14:46:36 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUtdB-0005NH-Ei for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 14:46:34 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EE46880625; Sat, 12 Aug 2023 14:46:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691865985; bh=RvXGsOMZShvfcTJDUeFD7Xoegps4Q/5ndUjLaoHENX8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nebrTUI3yEzQh/vGGohTIEqHKDhV85FzC/ORU/L9eR/rzt1Xcx3kP9lVxm+IliU4o F0JiRgs4WqtQOcYGfuyOPEb+Eqc/ZqEiK6TdENN0advQU5od4KItWULSi/yBNtH3KU 6H4Ku4IWmWoms6GF8+gZQt71A04EWwCobkr3zNmgM7G7ZPNAz89Sx2nVq4EbqQycMB 5bPEouH7Vd0sRGrucxDxojLz/2Tp9Vu4ye7vM4LmParPEVoSl8VhBv6pd/vFN7YQIF kLNgSzNlCn+MzfrFtYDiSWIY53T6ECq00VVK1G4mE7Oh/xzh0CMYqCVThRmGvDP2aZ 8mEmRUYqXMt/g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A2F3D803A2; Sat, 12 Aug 2023 14:46:25 -0400 (EDT) Received: from pastel (69-165-141-248.dsl.teksavvy.com [69.165.141.248]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 73070120247; Sat, 12 Aug 2023 14:46:25 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. In-Reply-To: <83msywg5a0.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Aug 2023 09:10:15 +0300") Message-ID: References: <83msywg5a0.fsf@gnu.org> Date: Sat, 12 Aug 2023 14:46: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.726 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 KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (---) Thanks, Stefan diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi index 34db0caf3a8..d2e397faf80 100644 --- a/doc/lispref/symbols.texi +++ b/doc/lispref/symbols.texi @@ -782,11 +782,16 @@ Symbols with Position @cindex symbol with position @cindex bare symbol -A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, -together with an unsigned integer called the @dfn{position}. These -objects are intended for use by the byte compiler, which records in -them the position of each symbol occurrence and uses those positions -in warning and error messages. +A @dfn{symbol with position} is a pair of a symbol, the @dfn{bare +symbol}, together with an unsigned integer called the @dfn{position}. +Symbol with position cannot themselves have entries in obarrays +(contrary to their bare symbols; @pxref{Creating Symbols}). + +Symbols with position are for the use of the byte compiler, which +records in them the position of each symbol occurrence and uses those +positions in warning and error messages. They shouldn't normally be +used otherwise. Doing so can cause unexpected results with basic +Emacs functions such as @code{eq} and @code{equal}. The printed representation of a symbol with position uses the hash notation outlined in @ref{Printed Representation}. It looks like @@ -798,11 +803,21 @@ Symbols with Position For most purposes, when the flag variable @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with -positions behave just as bare symbols do. For example, @samp{(eq -# foo)} has a value @code{t} when that variable -is set (but @code{nil} when it isn't set). Most of the time in Emacs this -variable is @code{nil}, but the byte compiler binds it to @code{t} -when it runs. +position behave just as their bare symbols would. For example, +@samp{(eq # foo)} has a value @code{t} when the +variable is set; likewise, @code{equal} will treat a symbol with +position argument as its bare symbol. + +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with +position continue to exist, but do not always behave as symbols. +Most importantly @code{eq} only returns @code{t} when given truly +identical arguments, for performance reasons. @code{equal} on the +other hand continues to treat a symbol with +position argument as its bare symbol. + +Most of the time in Emacs @code{symbols-with-pos-enabled} is +@code{nil}, but the byte compiler and the native compiler bind it to +@code{t} when they run. Typically, symbols with position are created by the byte compiler calling the reader function @code{read-positioning-symbols} diff --git a/src/fns.c b/src/fns.c index ac30670b3ac..fde4ef6b08b 100644 --- a/src/fns.c +++ b/src/fns.c @@ -5166,7 +5166,7 @@ sxhash_obj (Lisp_Object obj, int depth) hash = sxhash_combine (hash, sxhash_obj (XOVERLAY (obj)->plist, depth)); return SXHASH_REDUCE (hash); } - else if (symbols_with_pos_enabled && pvec_type == PVEC_SYMBOL_WITH_POS) + else if (pvec_type == PVEC_SYMBOL_WITH_POS) return sxhash_obj (XSYMBOL_WITH_POS (obj)->sym, depth + 1); else /* Others are 'equal' if they are 'eq', so take their From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 15:10:46 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 19:10:46 +0000 Received: from localhost ([127.0.0.1]:57493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUu0c-0000Il-6C for submit@debbugs.gnu.org; Sat, 12 Aug 2023 15:10:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUu0Y-0000IW-QO for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 15:10:44 -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 1qUu0T-0002Pv-Bd; Sat, 12 Aug 2023 15:10:37 -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=JHKV7jfFoJES8j/3U9SaAlzcMRN41BJLtnn3GKhmJ78=; b=JWbrcZsiGMOS cbS+sXnee7aryj4CDYe41Uz/DyeXI1KgO1R79ZYTwRSkezala4jIudecURHsz2z4ZBTyGtfUPZIXH kx2ZIbbyCjQOscC6t3hPzt2LHVRgKmP4h9qIsW2FmtIDG7gCN4edopQ1t8r1hn1Kn2LVhM2nzyCYk p4psK34oDLxcpqpzgDllQF0BkxeHy8W8QX/fVfK85fq3JdgPBaDl+PBsSumR2aYVRALOy/WLMR7Wk dntqM3n+LhsQDL/qAGwM5xmYhlEWR4G3fs+K4QfN8MAf3MGsDumC/TdBt9NmPFiy+/oFseEG7dSiI 2JRGVPKNwEACa9AvBD38TA==; Date: Sat, 12 Aug 2023 22:10:32 +0300 Message-Id: <83zg2wcc0n.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 12 Aug 2023 14:46:24 -0400) Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. References: <83msywg5a0.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (---) > From: Stefan Monnier > Cc: acm@muc.de, 65051@debbugs.gnu.org > Date: Sat, 12 Aug 2023 14:46:24 -0400 > > +A @dfn{symbol with position} is a pair of a symbol, the @dfn{bare > +symbol}, together with an unsigned integer called the @dfn{position}. > +Symbol with position cannot themselves have entries in obarrays ^^^^^^ "Symbols" From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 17:59:41 2023 Received: (at 65051) by debbugs.gnu.org; 12 Aug 2023 21:59:41 +0000 Received: from localhost ([127.0.0.1]:57716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUwe4-0004oP-Eb for submit@debbugs.gnu.org; Sat, 12 Aug 2023 17:59:40 -0400 Received: from mx3.muc.de ([193.149.48.5]:10660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUwdy-0004o6-GG for 65051@debbugs.gnu.org; Sat, 12 Aug 2023 17:59:38 -0400 Received: (qmail 33143 invoked by uid 3782); 12 Aug 2023 23:59:26 +0200 Received: from acm.muc.de (p4fe1539a.dip0.t-ipconnect.de [79.225.83.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Aug 2023 23:59:26 +0200 Received: (qmail 23584 invoked by uid 1000); 12 Aug 2023 21:59:26 -0000 Date: Sat, 12 Aug 2023 21:59:26 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (-) Hello, Stefan. On Sat, Aug 12, 2023 at 01:36:08 -0400, Stefan Monnier wrote: > > I'm proposing correctness, according to a coherent definition of > > symbols-with-pos-enabled. I was surprised indeed, and continue to be > > surprised, that you do not see this correction as a correction. To me, > > it's obvious. > I guess it's because you see it as a feature that (symbol-function > (position-symbol 'a 3)) signals an error when `symbols-with-pos-enabled` > is nil, .... No, not for that reason, but for the reasons I've outlined already at great length. > .... whereas I see it as a misfeature we should try and fix. What, you want to get a symbol-function from something which isn't a symbol? That's a misfeature? What's stopping you binding s-w-p-enabled to t for the operation you have in mind? In the current design, a SWP acts as its bare symbol when and only when symbols-with-pos-enabled is non-nil. Simple, consequent, and elegant. Why do you want to mess up that design? > > That is the case, yes. There are no current use-cases for SWPs with > > s-w-p-enabled nil. > Right. So all the code which behaves differently when encountering an > SWP depending on the value of `s-w-p-enabled` has only one of the two > branches tested. Not true. I have written tests into fns-tests.el (not yet committed) to test them. > My preference for making the behavior .... What behaviour, exactly? > .... oblivious to `s-w-p-enabled` (except for those rare cases where > it's needed for performance reasons) removes these untested code > paths. Rubbish! Those "untested code paths" will remain untested in your version until you test them. In my version, where I fix the bug, they have already been tested. And what exactly do you mean by "those rare cases where 's needed for performance reasons"? What's the , here? What exactly are you referring to? > In any case, here's my "counter offer". [ .... ] Thanks! It's incomplete, and there are several English usage errors in it. I'll get back to you tomorrow. But I still say we should fix the bug in the code. Anything you want to do with SWPs when you want to regard them as their bare symbols, you can do by binding symbols-with-pos-enabled to t. With your version of (not) fixing the bug, there is no convenient way to do a (full) equal operation on two SWPs when s-w-p-enabled is nil. Who knows what we might want to do with them in the future? > Stefan > diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi > index 34db0caf3a8..0eb3e8f211d 100644 > --- a/doc/lispref/symbols.texi > +++ b/doc/lispref/symbols.texi > @@ -782,11 +782,16 @@ Symbols with Position > @cindex symbol with position > @cindex bare symbol > -A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, > -together with an unsigned integer called the @dfn{position}. These > -objects are intended for use by the byte compiler, which records in > -them the position of each symbol occurrence and uses those positions > -in warning and error messages. > +A @dfn{symbol with position} is a pair of a symbol, the @dfn{bare symbol}, > +together with an unsigned integer called the @dfn{position}. > +They cannot themselves have entries in obarrays (contrary to their > +bare symbols; @pxref{Creating Symbols}). > + > +Symbols with position are for the use of the byte compiler, which > +records in them the position of each symbol occurrence and uses those > +positions in warning and error messages. They shouldn't normally be > +used otherwise. Doing so can cause unexpected results with basic > +Emacs functions such as @code{eq} and @code{equal}. > The printed representation of a symbol with position uses the hash > notation outlined in @ref{Printed Representation}. It looks like > @@ -798,11 +803,20 @@ Symbols with Position > For most purposes, when the flag variable > @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with > -positions behave just as bare symbols do. For example, @samp{(eq > -# foo)} has a value @code{t} when that variable > -is set (but @code{nil} when it isn't set). Most of the time in Emacs this > -variable is @code{nil}, but the byte compiler binds it to @code{t} > -when it runs. > +positions behave just as their bare symbols would. For example, > +@samp{(eq # foo)} has a value @code{t} when the > +variable is set; likewise, @code{equal} will treat a symbol with > +position argument as its bare symbol. > + > +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with > +position continue to exist, but do not always behave as symbols. > +Most importantly @code{eq} only returns @code{t} when given truly > +identical arguments, for performance reasons. @code{equal} on the > +other hand is not affected, > + > +Most of the time in Emacs @code{symbols-with-pos-enabled} is > +@code{nil}, but the byte compiler and the native compiler bind it to > +@code{t} when they run. > Typically, symbols with position are created by the byte compiler > calling the reader function @code{read-positioning-symbols} > diff --git a/src/fns.c b/src/fns.c > index d7b2e7908b6..5239eb73026 100644 > --- a/src/fns.c > +++ b/src/fns.c > @@ -5166,7 +5166,7 @@ sxhash_obj (Lisp_Object obj, int depth) > hash = sxhash_combine (hash, sxhash_obj (XOVERLAY (obj)->plist, depth)); > return SXHASH_REDUCE (hash); > } > - else if (symbols_with_pos_enabled && pvec_type == PVEC_SYMBOL_WITH_POS) > + else if (pvec_type == PVEC_SYMBOL_WITH_POS) > return sxhash_obj (XSYMBOL_WITH_POS (obj)->sym, depth + 1); > else > /* Others are 'equal' if they are 'eq', so take their > diff --git a/src/timefns.c b/src/timefns.c > index 151f5b482a3..7e030da3fcd 100644 > --- a/src/timefns.c > +++ b/src/timefns.c > @@ -1767,8 +1767,6 @@ DEFUN ("time-convert", Ftime_convert, Stime_convert, 1, 2, 0, > enum timeform input_form = decode_lisp_time (time, false, &t, 0); > if (NILP (form)) > form = current_time_list ? Qlist : Qt; > - if (symbols_with_pos_enabled && SYMBOL_WITH_POS_P (form)) > - form = SYMBOL_WITH_POS_SYM (form); > if (BASE_EQ (form, Qlist)) > return ticks_hz_list4 (t.ticks, t.hz); > if (BASE_EQ (form, Qinteger)) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 13 09:52:44 2023 Received: (at 65051) by debbugs.gnu.org; 13 Aug 2023 13:52:45 +0000 Received: from localhost ([127.0.0.1]:58429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVBWO-0001c2-Ks for submit@debbugs.gnu.org; Sun, 13 Aug 2023 09:52:44 -0400 Received: from mx3.muc.de ([193.149.48.5]:37279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVBWM-0001bn-Jz for 65051@debbugs.gnu.org; Sun, 13 Aug 2023 09:52:43 -0400 Received: (qmail 77468 invoked by uid 3782); 13 Aug 2023 15:52:36 +0200 Received: from acm.muc.de (p4fe152a2.dip0.t-ipconnect.de [79.225.82.162]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Aug 2023 15:52:35 +0200 Received: (qmail 22599 invoked by uid 1000); 13 Aug 2023 13:52:35 -0000 Date: Sun, 13 Aug 2023 13:52:35 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de 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 (-) Hello, Stefan. On Sat, Aug 12, 2023 at 14:07:39 -0400, Stefan Monnier wrote: > > Streamline time decoding and conversion > > * src/lisp.h (lisp_h_BASE2_EQ, BASE2_EQ): New macros and functions. > > * src/timefns.c (tzlookup, Fdecode_time): Use them. > > (Ftime_convert): Convert to symbol once, instead of many times. <===== > > .. form, if a SWP, gets replaced by its bare symbol, so that the > > following comparisons can be done by BASE_EQ rather than EQ. It's an > > optimisation, though I can't really see why it's worthwhile. > > If you remove that SWP handling, as you are proposing, you'll need to > > set these BASE_EQ's back to EQ's, too. > I see, thanks. > It's kind of odd, tho: it's the only function that does that, AFAICT. > I also can't see why `time-convert` should accept SWPs in addition to > bare symbols. In my book, it seems like passing it an SWP would be > a mistake. Anything which can accept symbols should accept SWPs when symbols-with-pos-enabled is non-nil. It's just basic consistency. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 13 11:27:35 2023 Received: (at 65051) by debbugs.gnu.org; 13 Aug 2023 15:27:35 +0000 Received: from localhost ([127.0.0.1]:60103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVD0B-0004Wb-9h for submit@debbugs.gnu.org; Sun, 13 Aug 2023 11:27:35 -0400 Received: from mx3.muc.de ([193.149.48.5]:40022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVD09-0004WO-G1 for 65051@debbugs.gnu.org; Sun, 13 Aug 2023 11:27:34 -0400 Received: (qmail 2692 invoked by uid 3782); 13 Aug 2023 17:27:27 +0200 Received: from acm.muc.de (p4fe152a2.dip0.t-ipconnect.de [79.225.82.162]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Aug 2023 17:27:27 +0200 Received: (qmail 23192 invoked by uid 1000); 13 Aug 2023 15:27:26 -0000 Date: Sun, 13 Aug 2023 15:27:26 +0000 To: Stefan Monnier Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83msywg5a0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, acm@muc.de, Eli Zaretskii 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 (-) Hello, Stefan. I haven't changed my view that the current handling of SWPs in equal is a bug, and that the bug should be fixed. Your patch isn't this fix. I continue to be uneasy about the contradictions in your attidude where, on the one hand, you say "anything we do here sucks equally" and describe this conversation as "bikeshedding", and on the other hand you're steamrolling over my clear vision for fixing the bug. Nevertheless, here are my comments on your proposed patch, as promised. On Sat, Aug 12, 2023 at 14:46:24 -0400, Stefan Monnier wrote: > Thanks, > Stefan > diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi > index 34db0caf3a8..d2e397faf80 100644 > --- a/doc/lispref/symbols.texi > +++ b/doc/lispref/symbols.texi > @@ -782,11 +782,16 @@ Symbols with Position > @cindex symbol with position > @cindex bare symbol > -A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, > -together with an unsigned integer called the @dfn{position}. These > -objects are intended for use by the byte compiler, which records in > -them the position of each symbol occurrence and uses those positions > -in warning and error messages. > +A @dfn{symbol with position} is a pair of a symbol, the @dfn{bare > +symbol}, together with an unsigned integer called the @dfn{position}. > +Symbol with position cannot themselves have entries in obarrays > +(contrary to their bare symbols; @pxref{Creating Symbols}). "Cannot" is inappropriate here, since there is nothing regrettable about SWPs not being stored in obarrays. "Contrary" is also inappropriate since there is no disagreement, opposition, or conflict between the two things. "As contrasted with" would be better. On the other hand, why didn't you just leave it as I had left it? > + > +Symbols with position are for the use of the byte compiler, which > +records in them the position of each symbol occurrence and uses those > +positions in warning and error messages. They shouldn't normally be > +used otherwise. Doing so can cause unexpected results with basic > +Emacs functions such as @code{eq} and @code{equal}. > The printed representation of a symbol with position uses the hash > notation outlined in @ref{Printed Representation}. It looks like > @@ -798,11 +803,21 @@ Symbols with Position > For most purposes, when the flag variable > @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with > -positions behave just as bare symbols do. For example, @samp{(eq > -# foo)} has a value @code{t} when that variable > -is set (but @code{nil} when it isn't set). Most of the time in Emacs this > -variable is @code{nil}, but the byte compiler binds it to @code{t} > -when it runs. > +position behave just as their bare symbols would. For example, > +@samp{(eq # foo)} has a value @code{t} when the > +variable is set; likewise, @code{equal} will treat a symbol with > +position argument as its bare symbol. This is suboptimal for your version. The paragraph is about Emacs's behaviour when symbols-with-pos-enabled is non-nil. You're including behaviour in this paragraph which you want to be independent of s-w-p-enabled. It really needs its own paragraph. > + > +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with > +position continue to exist, but do not always behave as symbols. The "do not always" is vaguer than it should be. The doc should be explicit about when SWPs behave as symbols, and when not. > +Most importantly @code{eq} only returns @code{t} when given truly > +identical arguments, for performance reasons. .... There's more to it than "for performance reasons". I think you could omit ", for performance reasons" since it is more likely to cause confusion than anything else. > .... @code{equal} on the > +other hand continues to treat a symbol with > +position argument as its bare symbol. "Continues to" is inappropriate here, since there is nothing continuous happening, nor a continuous "treating" of anything. A useful phrase might be "regardless of the value of @code{symbols-with-pos-enabled}". But as noted above for s-w-p-e's non-nil case, this doesn't belong in the paragraph about the behaviour when s-w-p-enabled is nil. > + > +Most of the time in Emacs @code{symbols-with-pos-enabled} is > +@code{nil}, but the byte compiler and the native compiler bind it to > +@code{t} when they run. > Typically, symbols with position are created by the byte compiler > calling the reader function @code{read-positioning-symbols} What's missing: (i) You'll need to amend the definition of symbols-with-pos-enabled in its @defvar, since you're changing it's meaning. (ii) You should document the behaviour of SWP's in the sections on `eq' and `equal'. (iii) See below. > diff --git a/src/fns.c b/src/fns.c > index ac30670b3ac..fde4ef6b08b 100644 > --- a/src/fns.c > +++ b/src/fns.c > @@ -5166,7 +5166,7 @@ sxhash_obj (Lisp_Object obj, int depth) > hash = sxhash_combine (hash, sxhash_obj (XOVERLAY (obj)->plist, depth)); > return SXHASH_REDUCE (hash); > } > - else if (symbols_with_pos_enabled && pvec_type == PVEC_SYMBOL_WITH_POS) > + else if (pvec_type == PVEC_SYMBOL_WITH_POS) > return sxhash_obj (XSYMBOL_WITH_POS (obj)->sym, depth + 1); > else > /* Others are 'equal' if they are 'eq', so take their Have you tested this thoroughly? Hash tables were one of the more troublesome things to get right when I was developing this stuff. It also needs documenting in the hash table chapter of the elisp manual. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 13 12:15:06 2023 Received: (at 65051) by debbugs.gnu.org; 13 Aug 2023 16:15:06 +0000 Received: from localhost ([127.0.0.1]:60133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVDk9-0005m1-Sb for submit@debbugs.gnu.org; Sun, 13 Aug 2023 12:15:06 -0400 Received: from mx3.muc.de ([193.149.48.5]:41404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVDk8-0005lB-00 for 65051@debbugs.gnu.org; Sun, 13 Aug 2023 12:15:04 -0400 Received: (qmail 66615 invoked by uid 3782); 13 Aug 2023 18:14:57 +0200 Received: from acm.muc.de (p4fe152a2.dip0.t-ipconnect.de [79.225.82.162]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Aug 2023 18:14:57 +0200 Received: (qmail 23572 invoked by uid 1000); 13 Aug 2023 16:14:56 -0000 Date: Sun, 13 Aug 2023 16:14:56 +0000 To: Eli Zaretskii Subject: Re: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Message-ID: References: <83h6pevnd0.fsf@gnu.org> <838raqvg91.fsf@gnu.org> <83r0ohsqmp.fsf@gnu.org> <83leepsn4t.fsf@gnu.org> <838rapskd2.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838rapskd2.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 65051 Cc: 65051@debbugs.gnu.org, monnier@iro.umontreal.ca 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 (-) On Sat, Aug 05, 2023 at 16:13:13 +0300, Eli Zaretskii wrote: > > Date: Sat, 5 Aug 2023 13:04:07 +0000 > > Cc: 65051@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > From: Alan Mackenzie > > > > No, only the bare symbol is in the obarray. The symbol with position > > > > itself is a pseudovector, with contents (i) a bare symbol (a Lisp_Object > > > > "pointing at" the obarray) and (ii) the unsigned integer position. > > > Please document this factoid in the ELisp manual, I think it's very > > > important, and having it undocumented is a Bad Thing. > > DONE. The change is near the top of the following patch, amended from > > the previous version. > LGTM, thanks. Here's the latest, probably final, version of the patch. It includes new tests in fns-tests.el, adds paragraphs to the descriptions of `eq' and `equal' in objects.texi, and removes the bit about symbols with position being "stored somewhat like vectors" (at the suggestion of Mattias E.). diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index ad079e0d63a..784d59720ed 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2206,6 +2206,10 @@ Equality Predicates the same object, and @code{eq} returns @code{t} or @code{nil} depending on whether the Lisp interpreter created one object or two. +If @var{object1} or @var{object2} is a symbol with position, @code{eq} +regards it as its bare symbol when @code{symbols-with-pos-enabled} is +non-@code{nil} (@pxref{Symbols with Position}). + @example @group (eq 'foo 'foo) @@ -2363,6 +2367,13 @@ Equality Predicates The @code{equal} function recursively compares the contents of objects if they are integers, strings, markers, vectors, bool-vectors, byte-code function objects, char-tables, records, or font objects. + +If @var{object1} or @var{object2} is a symbol with position, +@code{equal} regards it as its bare symbol when +@code{symbols-with-pos-enabled} is non-@code{nil}. Otherwise +@code{equal} compares two symbols with position by recursively +comparing their components. @xref{Symbols with Position}. + Other objects are considered @code{equal} only if they are @code{eq}. For example, two distinct buffers are never considered @code{equal}, even if their textual contents are the same. diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi index 34db0caf3a8..1f3b677d7fb 100644 --- a/doc/lispref/symbols.texi +++ b/doc/lispref/symbols.texi @@ -783,10 +783,15 @@ Symbols with Position @cindex bare symbol A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, -together with an unsigned integer called the @dfn{position}. These -objects are intended for use by the byte compiler, which records in -them the position of each symbol occurrence and uses those positions -in warning and error messages. +together with an unsigned integer called the @dfn{position}. Symbols +with position don't themselves have entries in the obarray (though +their bare symbols do; @pxref{Creating Symbols}). + +Symbols with position are for the use of the byte compiler, which +records in them the position of each symbol occurrence and uses those +positions in warning and error messages. They shouldn't normally be +used otherwise. Doing so can cause unexpected results with basic +Emacs functions such as @code{eq} and @code{equal}. The printed representation of a symbol with position uses the hash notation outlined in @ref{Printed Representation}. It looks like @@ -798,11 +803,20 @@ Symbols with Position For most purposes, when the flag variable @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with -positions behave just as bare symbols do. For example, @samp{(eq -# foo)} has a value @code{t} when that variable -is set (but @code{nil} when it isn't set). Most of the time in Emacs this -variable is @code{nil}, but the byte compiler binds it to @code{t} -when it runs. +positions behave just as their bare symbols would. For example, +@samp{(eq # foo)} has a value @code{t} when the +variable is set; likewise, @code{equal} will treat a symbol with +position argument as its bare symbol. + +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with +position continue to exist, but do not behave as symbols, or have the +other useful properties outlined in the previous paragraph. @code{eq} +returns @code{t} when given identical arguments, and @code{equal} +returns @code{t} when given arguments with @code{equal} components. + +Most of the time in Emacs @code{symbols-with-pos-enabled} is +@code{nil}, but the byte compiler and the native compiler bind it to +@code{t} when they run. Typically, symbols with position are created by the byte compiler calling the reader function @code{read-positioning-symbols} @@ -810,17 +824,17 @@ Symbols with Position @code{position-symbol}. @defvar symbols-with-pos-enabled -When this variable is non-@code{nil}, symbols with position behave +When this variable is non-@code{nil}, a symbol with position behaves like the contained bare symbol. Emacs runs a little more slowly in this case. @end defvar @defvar print-symbols-bare -When bound to non-@code{nil}, the Lisp printer prints only the bare symbol of -a symbol with position, ignoring the position. +When bound to non-@code{nil}, the Lisp printer prints only the bare +symbol of a symbol with position, ignoring the position. @end defvar -@defun symbol-with-pos-p symbol. +@defun symbol-with-pos-p symbol This function returns @code{t} if @var{symbol} is a symbol with position, @code{nil} otherwise. @end defun diff --git a/src/fns.c b/src/fns.c index d7b2e7908b6..9b300d503ff 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, /* A symbol with position compares the contained symbol, and is `equal' to the corresponding ordinary symbol. */ - if (SYMBOL_WITH_POS_P (o1)) - o1 = SYMBOL_WITH_POS_SYM (o1); - if (SYMBOL_WITH_POS_P (o2)) - o2 = SYMBOL_WITH_POS_SYM (o2); + if (symbols_with_pos_enabled) + { + if (SYMBOL_WITH_POS_P (o1)) + o1 = SYMBOL_WITH_POS_SYM (o1); + if (SYMBOL_WITH_POS_P (o2)) + o2 = SYMBOL_WITH_POS_SYM (o2); + } if (BASE_EQ (o1, o2)) return true; @@ -2824,8 +2827,8 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, if (ASIZE (o2) != size) return false; - /* Compare bignums, overlays, markers, and boolvectors - specially, by comparing their values. */ + /* Compare bignums, overlays, markers, boolvectors, and + symbols with position specially, by comparing their values. */ if (BIGNUMP (o1)) return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) == 0; if (OVERLAYP (o1)) @@ -2857,6 +2860,11 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind, if (TS_NODEP (o1)) return treesit_node_eq (o1, o2); #endif + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. */ + return (BASE_EQ (XSYMBOL_WITH_POS (o1)->sym, + XSYMBOL_WITH_POS (o2)->sym) + && BASE_EQ (XSYMBOL_WITH_POS (o1)->pos, + XSYMBOL_WITH_POS (o2)->pos)); /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el index 79ae4393f40..9c09e4f0c33 100644 --- a/test/src/fns-tests.el +++ b/test/src/fns-tests.el @@ -98,6 +98,26 @@ (should-not (equal-including-properties #("a" 0 1 (k "v")) #("b" 0 1 (k "v"))))) +(ert-deftest fns-tests-equal-symbols-with-position () + "Test `eq' and `equal' on symbols with position." + (let ((foo1 (position-symbol 'foo 42)) + (foo2 (position-symbol 'foo 666)) + (foo3 (position-symbol 'foo 42))) + (let (symbols-with-pos-enabled) + (should (eq foo1 foo1)) + (should (equal foo1 foo1)) + (should-not (eq foo1 foo2)) + (should-not (equal foo1 foo2)) + (should-not (eq foo1 foo3)) + (should (equal foo1 foo3))) + (let ((symbols-with-pos-enabled t)) + (should (eq foo1 foo1)) + (should (equal foo1 foo1)) + (should (eq foo1 foo2)) + (should (equal foo1 foo2)) + (should (eq foo1 foo3)) + (should (equal foo1 foo3))))) + (ert-deftest fns-tests-reverse () (should-error (reverse)) (should-error (reverse 1)) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 04 08:57:26 2023 Received: (at 65051-done) by debbugs.gnu.org; 4 Sep 2023 12:57:26 +0000 Received: from localhost ([127.0.0.1]:49070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qd98w-0003oB-As for submit@debbugs.gnu.org; Mon, 04 Sep 2023 08:57:26 -0400 Received: from mail.muc.de ([193.149.48.3]:34625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qd98t-0003nr-Ii for 65051-done@debbugs.gnu.org; Mon, 04 Sep 2023 08:57:24 -0400 Received: (qmail 68462 invoked by uid 3782); 4 Sep 2023 14:57:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693832236; h=date : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from : from; bh=IJUvZNiPGBNAsg1uPKDbJXmKPql7yZ3cmXtMWZJM95U=; b=fTowY1dwQypZeZylh6yrNN72kKBFcOLO+Lixr/NUfhsxM59P5Fc1Qr/V6G7Wq/1f/36HO NKyR2u+NKrgSRDqHippGL06BTcwjL9sfQ1Hel56JpB17CugTSZlmxp+go3Hba1aBQkn0pSq KXU7qduNTMnhLMBEkRRTl4M/5VPMwsJG4uuqu1DuWKXyox73KrXQitxhhTzPe9SMekAjsTk QLKi4klDr4msX691b1L68+SHwV6DKpdcbq8UNsm7YTdGFYfkGhqu4tC0ZV24aNr6BFCmBFX casedyGoEQi83KsCAbuMNEubcn9ZPRY6PAr2OBcmNH8eGRjGwu85d98/eScw== Received: from acm.muc.de (pd953a278.dip0.t-ipconnect.de [217.83.162.120]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Sep 2023 14:57:15 +0200 Received: (qmail 27450 invoked by uid 1000); 4 Sep 2023 12:57:15 -0000 Date: Mon, 4 Sep 2023 12:57:15 +0000 To: 65051-done@debbugs.gnu.org Subject: Re: bug#65051: Acknowledgement (internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65051-done Cc: acm@muc.de 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 (-) Bug fixed in the master branch, 2023-09-04. -- Alan Mackenzie (Nuremberg, Germany). From unknown Thu Aug 14 21:21:58 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 03 Oct 2023 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator