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

[Mattias Engdegård]

2 jan. 2020 kl. 09.38 skrev Paul Eggert <address@hidden>:

> [...] If it's not
> important, then I'd say the flonum/bignum deduplication patch is not urgent
> enough to put into Emacs 27.

Yes, we'd better leave Emacs 27 alone, except for improved documentation.

I'm feeling queasy about hash-consing floats and bignums. Benchmarking is 
treacherous in several regards: there is currently very little use of bignums 
for obvious reasons, and Emacs sessions are famously long-lived. The real 
problem is Emacs's archaic non-generational GC.

Most bignums aren't very big; they tend to obey a power law. Particularly 
common are full-word integers, just a bit or two larger than fixnums. They crop 
up in various kind of system interfaces (IDs, handles, addresses etc), FFIs, 
checksums/hashes, fields in binary files and protocols, and so on. Having 
bignums, we may see quite a few of these.

In other words, making bignums/flonums slower may seem to have no bad effects, 
until suddenly it has.

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

That sentence mentions eq and eql as equally inferior alternatives to =, which 
isn't necessarily helpful.

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

We should be allowed to make recommendations as long as it's made clear that 
experts (ahem) can do what they please, no? The user may otherwise not realise 
that using eql instead of eq (1) makes their code more portable, and (2) 
extends it to a greater range of input data, both of which will make it useful 
in a wider range of circumstances.

That said, your patch is fine! One sentence, though:

> +If they were computed separately but happen to have the same value
> +and the same non-fixnum numeric type, then they might or might not be
>  the same object, and @code{eq} returns @code{t} or @code{nil}
>  depending on whether the Lisp interpreter created one object or two.


The "computed separately" qualifier is a bit too vague, but the statement also 
risks becoming too strong. Can't we just say that equal non-fixnum numbers may 
or may not be eq?