Re: Bug#38708: eq vs eql in byte-compiled code

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> For example, this code will produce t:
>> (defun my-eq (a b) (eq a b))
>> (defun f () (xor (eq 1.0 1.0) (my-eq 1.0 1.0)))
>> (byte-compile 'f)
>> (f)

Such paradoxes are just what you get from using `eq`.
We could eliminate this one in some ad-hoc way, but there'd still be a
million others.  AFAIK people here have decided (to my chagrin) that
`eq` should stay distinct from `eql`, so these paradoxes are considered
as "features".

> How about going a bit further, and globally deduplicating all flonums
> and bignums that result from low-level text-to-number conversion and
> module imports?

I don't see the benefit.  All it would do, AFAICT, is to make it more
difficult to "manually" reproduce/show those eq-paradoxes, so people
will be even more stumped when their code gets nil whereas redoing the
test by hand with M-: returns t (which again, is part of the "fetureset"
of `eq`, but still).

We could/should do hash-consing of bignums, tho.  It won't affect code
that doesn't use bignums, and should have a fairly minor performance
cost for bignums while making their semantics more clean.


        Stefan