Re: Comparing symbol-with-position using eq

[Daniel Colascione]

> Hello, Alex.
>
> On Fri, Apr 05, 2019 at 11:05:59 -0600, Alex wrote:
>> Hello, Alan.
>
>> Alan Mackenzie <address@hidden> 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.

I'm also concerned that by overloading eq this way we'll make it easy to
"lose" information about positions. In general, when (eq a b), we can
substitute a for b and vice versa. The objects are equivalent in the
strongest sense. Now, they're not equivalent, and choosing a instead of b
can lead to subtle bugs, especially since we're talking about error-path
and warning-path code that might not be frequently exercised.

You mention that we'd need to change the use of EQ throughout the byte
compiler in order to work with positional symbols properly. Can we just do
that, in one big renaming patch? In cases where we don't want positions,
we can just define a macro making the new eq-for-position function
equivalent to eq.

But yes, it's kind of unfortunate that we haven't been using an explicit
AST representation.