On 1/1/20 4:38 AM, Mattias Engdegård wrote:

> The flonum/bignum deduplication patch is only in master at this point. If you think it emacs-27 would benefit from a version of it that specifically excludes flonums, this could of course be arranged.

This depends on how important we want (eq integer integer) to work in Emacs 27
as it did in Emacs 26. If it's important, then we hash-cons bignums in Emacs 27
(using a patch like the one I just emailed you), and in that case the
flonum/bignum deduplication patch does not matter for bignums. If it's not
important, then I'd say the flonum/bignum deduplication patch is not urgent
enough to put into Emacs 27.

> The standard rule should be not to use 'eq' for numbers of any kind.

The manual already says this:

To test numbers for numerical equality, you should normally use
@code{=} instead of non-numeric comparison predicates like @code{eq},
@code{eql} and @code{equal}.

> Attached is a proposed documentation patch for emacs-27. While not perfect, it should at least be an improvement (and fixes at least one error).

I found that a bit too dogmatic about avoiding eq on numbers, as it's reasonable
to use eq in many cases (I do it in my code, you do it in your code, and as long
as you know what you're doing it's OK). How about the attached patch instead?
(It does not assume the global bignum deduplication patch.)

>> 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?
>> That conversion is slow and/or rare already, and if we're lucky deduplication
>> wouldn't make things noticeably slower and wouldn't be much work.
> 
> Maybe, but wouldn't that slow down reading .elc files (and still not shorten individual constant vectors)?

Almost surely it would, yes. I don't know how important that would be. Perhaps
we'd get performance back elsewhere. Only one way to find out, I suppose....