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

["Mattias Engdegård" <mattiase@acm.org>]

2 jan. 2020 kl. 09.38 skrev Paul Eggert <eggert@cs.ucla.edu>:

> [...] 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?