bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode

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

29 dec. 2019 kl. 18.29 skrev Pip Cet <pipcet@gmail.com>:

> On Sat, Dec 28, 2019 at 6:50 PM Mattias Engdegård <mattiase@acm.org> wrote:
>> Elisp has a few 'boundedly undefined' parts which would be avoided in a greenfield design but that we are more or less stuck with for the time being, and probably should paint in large letters on the first page of the manual. Such as: don't use eq for numbers; don't mutate literals (strings, conses, vectors); etc.
> 
> I don't think we're stuck with those two, and I don't think we should
> be making them worse than they already are (in Emacs 26.3).

I have some sympathy for the eq=eql idea but the faster we make elisp, the harder such a change becomes (since the difference in speed becomes more apparent).

> [...] I think your change isn't as
> trivial as it seems at first glance, and we shouldn't do it for Emacs
> 27, but it's fine on the master branch and might help us shake out
> some bugs (and, strategically, the paradoxical behavior observed with
> your patch is a good argument for making eq and eql synonymous).

Thanks for clarifying. I'll try to be brief; we seem to agree on the important points.

>> In my experience people seem to have little trouble understanding that eq shouldn't be used to compare numbers.
> 
> Not my experience.

Sorry, I meant observing and teaching programming in Scheme and (Common) Lisp, both having a similar eq/eql split. Elisp is special in that eq has until now always worked for all integers, so naturally there is a substantial body of code written that way, both inside and outside Emacs.

> In fact, anyone who reads
> https://www.gnu.org/software/emacs/manual/html_mono/elisp.html#Equality-Predicates
> today would come away with the reassuring knowledge that "If object1
> and object2 are integers with the same value, they are considered to
> be the same object (i.e., eq returns t)."

Good point. The revised text (in Emacs 27) still gives fixnums a prominent place; perhaps it should be toned down?

> So whether you learn by experience or by "stable" documentation,
> you'll pick up the habit of comparing integers with eq.

Yet habits will have to change whether the deduplication change stays or not, since we have bignums and eq≠eql. I'm confident that people can learn new rules if properly taught.

> What are the rules, then? "Use eql, except if you're comparing against
> a small integer, when eq is fine, or a character, which might not be
> that small but will be fine, or a number you know from studying the
> Emacs internals is a fixnum"?

If it were up to me, the simple rule should be not to use eq for numbers. Anything else is fine-print.

> My impression was people were very careful to use eq and EQ whenever
> they could prove the numbers were still in fixnum range.

Maybe the manual put excessive emphasis on performance?
Programmers who learn from a too early reading of code hand-tuned by experts tend to pick up some questionable habits no matter the language.

> (defun f ()
>  (cond
>   ((eq 1.0 1.0) 1)
>   ((my-not-eq 1.0 1.0) 2)
>   (t 3))))
> 
> produces 3 here, with your patch and standard byte compilation. That
> seems just as paradoxical to me.

It's not hard to produce a contradiction if starting from a false premise, in this case "eq on numbers yields a useful or at least consistent result".

The same is true for your hash-table example: replace 1.0 with "abc", and you will get the same (contradictory-looking) result, since the compiler deduplicates strings, too. Distinct literals may or may not be eq.

>> Good thing that the change works in that other direction then!
> 
> Sorry, I may have been ambiguous: With your patch, (eq 1.0 1.0) is t
> without optimization, nil with optimization. That's the direction I
> meant.

I understand, and it is I who should apologise for the clever tone in my answer.