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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 4 Feb 2022 19:33:28 +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>
> 
> > > >   . comparison of a symbol and symbol-with-pos should only compare the
> > > >     symbol part, and disregard the "pos" part, right?
> 
> Yes.
> 
> > > >   . 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.
> 
> OK, I don't think we can improve the performance by the use of a struct
> containing the symbol followed by the position.  I'm not sure what more I
> can add.

Then let me ask guiding questions.

First, are symbols-with-pos supposed to happen in bytecode that
doesn't deal with byte compilation?  If yes, why/when would such
objects appear in GP bytecode?

> We cannot extend struct Lisp_Symbol with the position, since a single
> symbol typically occurs several times in different positions.

So?  That would just mean there could be several different Lisp
objects whose "symbol parts" are identical, but the position parts are
different.  Right?

> > What is there in a symbol-with-pos except the symbol and the position?
> 
> There is the symbol, the position, and a pseudovector header.

The pseudovector part is not needed if we just extend Lisp_Symbol to
have an additional field 'position'.