GNU bug report logs - #38708
[PATCH] Deduplicate flonum and bignum constants in bytecode

Previous Next

Full log

Message #16 received at 38708 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 38708 <at> debbugs.gnu.org
Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in
 bytecode
Date: Sat, 28 Dec 2019 16:49:05 +0100

27 dec. 2019 kl. 18.07 skrev Pip Cet <pipcet <at> gmail.com>:

> I don't have a strong opinion about this (well, I do, actually: 'eq
> and 'eql should be equal), but my impression from the last time this
> was discussed is that the problems this causes (different code
> behavior for byte-compiled code versus evaluated code) outweighed the
> benefits (very tiny code size reduction).

Thank you for inspecting my change! And sorry, I didn't know this had been debated before. Is there a record of that discussion anywhere?

> Most importantly, I think that we should be able to be define
> 
> (defun f () (eq 18446744073709551616 18446744073709551616))
> 
> That function should always return t on sane systems that have eq =
> eql, and always return nil on systems that have <64 bits in a fixnum
> and the old-style eq.

I'm not sure I understand. Surely such a criterion imposes a rather low limit on permissible optimisations? For example, shouldn't

(eq (ash 1 x) (ash 1 x))

be allowed to be optimised to t (after CSE, say), even if x can be 64, despite the fact that interpreted or low-optimised compiled code would yield nil in that case?

Perhaps the change should really be done on the emacs-27 branch, to avoid changing bignum behaviour, but that is just a slightly weaker version of the same restriction. Unless we decide to turn eq into a synonym for eql, eq is a one-sided conservative approximation of eql for bignums and flonums.

> Anyway, I still think the right course of action here is to fix (or
> deprecate) eq rather than changing minor details of the byte compiler
> in incompatible ways. However, if we decide the gain is significant
> for floating point numbers, let's restrict this to floating point
> numbers and leave bignums alone?

What would anyone gain from such a restriction? And the change is minor because it's a small thing to do; what I thought looked like an obvious oversight, or one that made more sense back when Elisp didn't have bignums.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.