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

[Mattias Engdegård]

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.