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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Feb 04, 2022 at 21:46:06 +0200, Eli Zaretskii wrote:
> > 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?

Symbols with pos are intended to be used only in compilation, native- as
well as byte-.  They mustn't be output to .elc files.

> If yes, why/when would such objects appear in GP bytecode?

What does "GP" mean here, please?

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

I suppose so, yes.

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

Yes.  I'm not sure we can do this, though.

-- 
Alan Mackenzie (Nuremberg, Germany).