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

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

7 aug. 2023 kl. 11.44 skrev Alan Mackenzie <acm@muc.de>:

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

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.)
> 
> 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`.
> 
> 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.