From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: 65051@debbugs.gnu.org
Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.
Date: Thu, 10 Aug 2023 10:28:55 -0400 [thread overview]
Message-ID: <jwvedkbui8u.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <ZNSqeeBaFM9lpdX0@ACM> (Alan Mackenzie's message of "Thu, 10 Aug 2023 09:14:33 +0000")
>> 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?
> <sigh> 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é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. ]
>> 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
next prev parent reply other threads:[~2023-08-10 14:28 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 14:00 bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled Alan Mackenzie
2023-08-04 14:32 ` Eli Zaretskii
2023-08-04 14:59 ` Alan Mackenzie
2023-08-04 15:27 ` Eli Zaretskii
2023-08-04 17:06 ` Alan Mackenzie
2023-08-04 18:01 ` Eli Zaretskii
2023-08-05 10:45 ` Alan Mackenzie
2023-08-05 10:57 ` Eli Zaretskii
2023-08-05 11:52 ` Alan Mackenzie
2023-08-05 12:13 ` Eli Zaretskii
2023-08-05 13:04 ` Alan Mackenzie
2023-08-05 13:13 ` Eli Zaretskii
2023-08-13 16:14 ` Alan Mackenzie
2023-08-05 14:40 ` Mattias Engdegård
2023-08-05 16:59 ` Alan Mackenzie
2023-08-05 17:02 ` Mattias Engdegård
2023-08-05 21:07 ` Alan Mackenzie
2023-08-06 13:37 ` Mattias Engdegård
2023-08-06 15:02 ` Alan Mackenzie
2023-08-07 8:58 ` Mattias Engdegård
2023-08-07 9:44 ` Alan Mackenzie
2023-08-09 18:45 ` Mattias Engdegård
2023-08-07 3:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-07 9:20 ` Alan Mackenzie
2023-08-08 2:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-08 15:33 ` Alan Mackenzie
2023-08-10 3:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-10 9:14 ` Alan Mackenzie
2023-08-10 14:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-08-10 18:35 ` Alan Mackenzie
2023-08-12 5:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-12 6:10 ` Eli Zaretskii
2023-08-12 18:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-12 19:10 ` Eli Zaretskii
2023-08-13 15:27 ` Alan Mackenzie
2023-08-12 10:41 ` Alan Mackenzie
2023-08-12 18:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-13 13:52 ` Alan Mackenzie
2023-08-12 21:59 ` Alan Mackenzie
2023-08-11 0:51 ` Dmitry Gutov
2023-08-11 10:42 ` Alan Mackenzie
2023-08-11 11:18 ` Dmitry Gutov
2023-08-11 12:05 ` Alan Mackenzie
2023-08-11 13:19 ` Dmitry Gutov
2023-08-11 14:04 ` Alan Mackenzie
2023-08-11 18:15 ` Dmitry Gutov
[not found] ` <handler.65051.B.169115764532326.ack@debbugs.gnu.org>
2023-09-04 12:57 ` bug#65051: Acknowledgement (internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.) Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvedkbui8u.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=65051@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).