bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.

[Stefan Monnier]

>> 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