From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode Date: Sat, 28 Dec 2019 19:50:14 +0100 Message-ID: References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="245492"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38708@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 28 19:51:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ilHBD-0011fu-Af for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 19:51:15 +0100 Original-Received: from localhost ([::1]:45560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilHBC-0004iI-45 for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 13:51:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41971) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilHB2-0004bj-Dq for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 13:51:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilHB0-0002VP-Qz for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 13:51:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilHB0-0002Rr-9U for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 13:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ilHB0-0007lm-5n for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 13:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2019 18:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38708 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 38708-submit@debbugs.gnu.org id=B38708.157755902129820 (code B ref 38708); Sat, 28 Dec 2019 18:51:02 +0000 Original-Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 18:50:21 +0000 Original-Received: from localhost ([127.0.0.1]:58905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilHAK-0007kt-L9 for submit@debbugs.gnu.org; Sat, 28 Dec 2019 13:50:20 -0500 Original-Received: from mail204c50.megamailservers.eu ([91.136.10.214]:39068 helo=mail193c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilHAI-0007kj-E6 for 38708@debbugs.gnu.org; Sat, 28 Dec 2019 13:50:19 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1577559016; bh=9AFKQnUl0f+xly7/iVf6ztCrZls/MBqZpGDPzKxnRQU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=J/v3fHDN7Q8O61VM0JwOESDLlkC4QcdTak3idLwQNDZlPIpHeFG6zGJAE83A+Pjv1 nJ/vpTn0k9oT/OBbybjOBGNuosF3b4Mv38cS4SoN64k9tj5OdDeihqpCKdx0DspVuq RYY2wF1KZpJyX0kCPoxijMe1htP/YpviOoAon0PQ= Feedback-ID: mattiase@acm.or Original-Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id xBSIoEgJ008461; Sat, 28 Dec 2019 18:50:16 +0000 In-Reply-To: X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B0211.5E07A3E8.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=SamJicZu c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=pGLkceISAAAA:8 a=1Gq5nMdsZnA3-OuzRqsA:9 a=PHlR3jaiKm9eYfBz:21 a=CYGD2jIW9IQvWaQT:21 a=CjuIK1q_8ugA:10 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173860 Archived-At: 28 dec. 2019 kl. 17.36 skrev Pip Cet : > It was part of the rather extensive eq-vs-eql debate, I'm afraid. Thank you, I think I have heard most of the possible arguments in one = form or the other over the years... > I'll try to be clear about this: I think anything but making eq and > eql synonymous is likely to cause problems that drive programmers away > from Elisp. Actually, I can think of a bunch of more pressing issues, both in terms = of the language, its implementation, and the framework. > But there are axioms that programmers can rely on that are > stronger than what eq actually promises. For example, two objects > might be thought either to be eq to each other or not, but code such > as this: >=20 > (defun my-not-eq (x y) (not (eq x y))) >=20 > (defun always-t () > (or (eq 18446744073709551616 18446744073709551616) > (my-not-eq 18446744073709551616 18446744073709551616))) >=20 > (byte-compile 'always-t) > (always-t) >=20 > will yield unexpected results. 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'm not sure I understand. Surely such a criterion imposes a rather = low limit on permissible optimisations? >=20 > Yes, it does. I think any change in the behavior of eq, except for > making it equal to eql, is likely to break code that's out there > somewhere (and that doesn't mean we hear about it; more likely, people > end up abandoning Elisp and using JavaScript instead). So the second > best option is to keep the current (pre-patch) behavior in which (eq > 1.0 1.0) is reliably nil, IMHO. (Javascript's notion of equality, I'm told, is not quite a model of = elegance and simplicity, but perhaps that was your point.) In my experience people seem to have little trouble understanding that = eq shouldn't be used to compare numbers. If anything, the introduction = of bignums helps driving the point home: up to and including Emacs 26, = elisp programmers could get away with eq for integers but not = floating-point numbers. Now, the rules are simpler. (Characters still = get a free pass, I suppose.) While we could document a safe range of fixnums for which eq applies, = it's probably better not to. I definitely don't think it's worth propping up broken code that somehow = relies on the non-identity of float literals (bignums isn't a worry = yet). Such code is not only wrong, it's fragile: fragile in the face of = changes to elisp, and of innocent-looking changes to the code itself, = such as introducing variables for values. This doesn't mean that I would necessary be opposed to making eq a = synonym for eql; just that it would be a rather more momentous decision = that I won't bore anyone by discussing here (although I'd be happy to = talk about it over a drink if we meet one day). Has any state-of-the-art = Scheme or Lisp implementation ever taken that step? > Technically, I think code such as >=20 > (cond ((eq a b) 1) ((not (eq a b)) 2) (t 3)) >=20 > is allowed to return 3. We should attempt not to make changes that > make this more likely, though. Given the state of elisp byte-code optimisation, there is plenty of room = for improvements before such semantics become unavoidable. In = particular, the committed change does not in any way enable such = paradoxical behaviour. > (Again, is this really what we want? If you can't modify an eq-based > hash table reliably, because keys might have become eq (and thus > overwrite each other) that weren't eq when you checked the hash table, > what can you use such hash tables for?) Are you arguing that this would be a consequence of the constant = deduplication? When eq-based hash tables are not for use with numeric = keys anyway? > You're right, that is eq's contract. But people do misuse it, and one > of the things they wouldn't expect is that optimization results in > things becoming non-eq that were eq before optimization; I think the > other direction is much less problematic. Good thing that the change works in that other direction then! >> 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. >=20 > Well, Elisp has had floats for a while, and bignum constants appear to > be nonexistent, so far. In other words, there is no broken bignum code that can break. Obviously it's a small change, and one that I'm prepared to revert if = required. But I would like to understand the reason and principles = behind it. I want elisp to be faster; we have promised exactly nobody = that each numeric literal has its own identity, nor is that a reasonable = assumption by a programmer to make.