Re: Comparing symbol-with-position using eq

[Alan Mackenzie <acm@muc.de>]

Hello, Alex.

On Fri, Apr 05, 2019 at 11:05:59 -0600, Alex wrote:
> Hello, Alan.

> Alan Mackenzie <acm@muc.de> writes:

> > On Thu, Apr 04, 2019 at 22:49:22 -0600, Alex wrote:

> >> I apologize if this topic already reached its conclusion, but IMO
> >> having eq return true for two different object types is quite
> >> surprising behaviour.

> > We are comparing two symbols, both of which are 'foo, but one of which is
> > annotated with its position in a source file.  The two symbols are the
> > same symbol.

> Is it not comparing a symbol with a pseudovector containing that symbol
> and a position?

At the machine code level, that is what it's doing, yes.

> > I understand the reaction to the idea, though.  Even though the
> > representation of these two objects is different, conceptually they are
> > the same object.

> Similar objects, but I don't believe that's enough for eq. Consider that
> it's regarded non-portable in Lisp to compare integers with eq since the
> same number may be represented by different objects, or (eq 3 3.0), or
> (eq (list 1 2) (list 1 2)).

The point is that comparing 'foo with (Symbol "foo" at 339) with `eq',
and returning t doesn't do any harm.  On the contrary, it enables correct
source positions to be output in byte compiler warning messages.  That it
does no harm is verified by the fact that a make bootstrap with such
annotated symbols works.

However, there is a slight slowdown in this Emacs, compared with the
master branch.  The powers that be have intimated that this slowdown is
unacceptable, so I'm having to make more far reaching changes in the C
code to confine this slowdown to byte compilation.

> > But consider: on a make bootstrap I did last night, there were 332
> > warning messages from the byte compiler.  Of these, only 80 gave the
> > correct line/column position, the other 252 being wrong.  There have been
> > several bug reports from users complaining about such false positions.
> > This is what I'm trying to fix.

> I agree that it's a problem very much worth fixing; thank you for
> working on it.

It's a difficult problem.  The idea of annotating symbols with a source
position (this was Stefan M.'s idea) is the only idea which has even come
close to solving this problem.  I was struggling with another approach
back in 2016 which involved keeping the source location in a hash table
indexed by the corresponding cons cell.  This effort collapsed from the
sheer tedium of the changes needed, coupled with the unlikelihood of
getting the changes working, to say nothing of the fact it would have
rendered the byte compiler unreadable.

> >> Is it out of the question to leave eq alone and introduce, e.g.,
> >> eq-excluding-position that strips possible positions before comparison?

> > It is, rather.  To implement this would involve rewriting everything
> > which calls eq and is used by the byte compiler, to call
> > eq-excluding-position instead.  These functions would need to exist in
> > two versions.  There are rather a lot of functions which use eq.  ;-)

> Why would you need to rewrite the helper procedures that the byte
> compiler uses? What about stripping the position at each relevant call
> site?

I'm not sure what you mean here.  If by "relevant call site" you mean
"places where `eq' is used", there are just too many of them.  They're in
the C code as well as the Lisp.  If you mean "places where the helper
procedures are called", then that stripping the positions would negate
the whole point of the symbols with positions, since it is these helper
procedures which output warning messages.

Or did you mean something else?

-- 
Alan Mackenzie (Nuremberg, Germany).