From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Date: Thu, 10 Aug 2023 09:14:33 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38742"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65051@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 10 11:15:28 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qU1lP-0009lb-2P for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Aug 2023 11:15:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qU1lE-0001cR-FZ; Thu, 10 Aug 2023 05:15:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qU1l2-0001Wj-72 for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 05:15:05 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qU1l0-0007Wp-4b for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 05:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qU1kz-000697-Ry for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 05:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Aug 2023 09:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65051 X-GNU-PR-Package: emacs Original-Received: via spool by 65051-submit@debbugs.gnu.org id=B65051.169165888523587 (code B ref 65051); Thu, 10 Aug 2023 09:15:01 +0000 Original-Received: (at 65051) by debbugs.gnu.org; 10 Aug 2023 09:14:45 +0000 Original-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 Original-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 Original-Received: (qmail 12195 invoked by uid 3782); 10 Aug 2023 11:14:34 +0200 Original-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 Original-Received: (qmail 17548 invoked by uid 1000); 10 Aug 2023 09:14:33 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267110 Archived-At: 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).