Re: Time to merge scratch/correct-warning-pos into master, perhaps?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 4 Feb 2022 18:31:01 +0000
> Cc: gregory@heytings.org, monnier@iro.umontreal.ca, mattiase@acm.org,
>   larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Can you explain why we need to complicate EQ so much to account for
> > symbols-with-pos?
> 
> There are four possible ways the two Lisp objects might match - each
> object can be either a bare symbol, or a symbol with pos, giving four
> possibilities.  It's worth noting that the last three possibilities are
> cut off completely by the check on symbols-with-pos-enabled, except
> during compilation.

I don't see how the number of combinations is relevant.  If all you
need to compare is the symbol part, then whether there's something
after it in memory is not interesting and doesn't affect comparison.

> Specific questions:
> 
> >   . comparison of a symbol and symbol-with-pos should only compare the
> >     symbol part, and disregard the "pos" part, right?
> >   . if so, couldn't we implement symbol-with-pos as a struct that has
> >     the symbol at its beginning, and then use memcmp to compare only
> >     that part?
> 
> > Or what am I missing?
> 
> I don't think we can get anywhere that way.  What gets compared in EQ
> are the Lisp_Object's, which are typically already in processor
> registers.  I don't think we typically have a pointer to memory
> containing the symbol with position.

Sorry, I don't understand how this answers my questions.

> Don't forget that the position attaches to the symbol OCCURRENCE,
> not the symbol itself.

I don't understand what I need not to forget, please elaborate.

What is there in a symbol-with-pos except the symbol and the position?

(And please be more cooperative and forthcoming, since my questions
are meant to help make this feature less expensive, otherwise there's
a real chance of the feature to be removed, something I hope you don't
want.)