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

[Mattias Engdegård]

31 dec. 2019 kl. 18.38 skrev Paul Eggert <address@hidden>:

> One possible compromise would be to duplicate only bignums in the emacs-27
> branch, while reserving flonum deduplication for the master branch. This would
> help a bit with now-incorrect code that uses eq to compare bignum values, 
> while
> not introducing flonum "paradoxes".

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.

In general, though, my impression is that the likelihood of any trouble in 
practice is nil (speaking as the author of the change, of course).

More important is how to present equality semantics to the user, through 
documentation, NEWS, and examples. This includes:

- What 'eq' can be used for: what we recommend, and what we guarantee.
- Which equality relation to use and when: eq, eql, equal, =, string-equal, etc.

For example, while we have to guarantee that 'eq' works for fixnums for 
compatibility, it may be unwise to give this fact prominence in the 
documentation. One of the benefits of bignums is that users no longer have to 
worry about fixnum ranges in most cases. The standard rule should be not to use 
'eq' for numbers of any kind.

Whether to specifically mention characters as eq-comparable is a matter of 
judgement. (Neither CL nor Scheme guarantee that characters can be used with 
eq/eq?.) Of course my own code is littered with eq for characters, but do as I 
say...

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

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

0001-Clarify-eq-on-numbers.patch
Description: Binary data