From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode Date: Sat, 28 Dec 2019 16:36:54 +0000 Message-ID: References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="260453"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38708@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 28 17:38:13 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 1ilF6S-0015dp-P9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 17:38:12 +0100 Original-Received: from localhost ([::1]:44542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilF6R-0007jj-Ic for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 11:38:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50205) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilF6J-0007jR-DL for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 11:38:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilF6H-00050c-Vm for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 11:38:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52853) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilF6H-00050H-PA for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 11:38:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ilF6H-0004gD-JZ for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 11:38:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2019 16:38:01 +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.157755105817952 (code B ref 38708); Sat, 28 Dec 2019 16:38:01 +0000 Original-Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 16:37:38 +0000 Original-Received: from localhost ([127.0.0.1]:58825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilF5u-0004fU-3v for submit@debbugs.gnu.org; Sat, 28 Dec 2019 11:37:38 -0500 Original-Received: from mail-oi1-f172.google.com ([209.85.167.172]:46817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilF5s-0004fG-QM for 38708@debbugs.gnu.org; Sat, 28 Dec 2019 11:37:37 -0500 Original-Received: by mail-oi1-f172.google.com with SMTP id p67so10220607oib.13 for <38708@debbugs.gnu.org>; Sat, 28 Dec 2019 08:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sKbXJslmbbyKOR3fibRgGXJ8XseEllA6bLzz7XBbMtQ=; b=b+S6Fawvs+2Pr+DRN71akQPYmzPg3cktoWlK2II0ASIO8XJ8umlnaHsrNPTpmZ4FkO RKBIPUTl6hhg1P76XHzUOjJC2NBf2UTmtcSNfzQ9R5xzln/VIVWbAtsM7OExz93t2eTL YtInGJtzgb6/gUTPe0mS0B/OZ9+i8nhqQnwaGAu7cJ7qn4/jrTPMwJT2XL/L4XXCSRqi Yi5aiRYRblvBA6gqT7U0Odh1ATp0Sy8/4nyuCZSyygVFQbeJHAfvbx7yYAOeEhlRRdCv nUpp+eVxP0I74IhKP8bfXDpJm5sz577OjfONycfF9dUgmW8u/iey9NxjKeHMXlb24IqD 5RiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sKbXJslmbbyKOR3fibRgGXJ8XseEllA6bLzz7XBbMtQ=; b=WmSywMF6PX/UtE6ZngXAjjfCExgIc1vA8cN8uwTHwQxTDCxBkqynnPQv14g8D9Jr59 KsN4tq3Rzxo7+qEbejrk1Sy5BU3w9pZg0Yh6ePKCVZZaLSPR+EngUXLVFcZJsBT6f4zQ 7Ye5WdyH2skWIScfT4rjDhsRedXTjQN4ERl4qLvEYNQ0avL+SnVE/TWF/VhoVP9gY8uT +YAtXkf69WuhGN7Qz09uQ16N+a+0iFg/cXIy0nGhVAMo4PWEOkPXcJKqQ3WOy+3eh8xp efCq9aK6BaWnrTBxukDCAC38plr2HsVVGJAw6C63esZFRv7t+8CbKFy5tOCqyBt0L7mq kYrg== X-Gm-Message-State: APjAAAXb3l0u750ISXDIKQpIMwU/fI+nFOtOUeOeyQEZcEtrHZ0pVnZ2 jM+BqNpncxKDLyUnNVDKOC4w0ogn9QAXbsM9dEs= X-Google-Smtp-Source: APXvYqySar72IgQ9/5mDIN/PhUEVV4ACgt8ZvracoSf++JoNMwLpMyhI7pGG+KH8bcrASEsjiWmAg+FE6Egb/fY3lao= X-Received: by 2002:a54:4396:: with SMTP id u22mr4630300oiv.128.1577551050911; Sat, 28 Dec 2019 08:37:30 -0800 (PST) In-Reply-To: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> 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:173852 Archived-At: On Sat, Dec 28, 2019 at 3:49 PM Mattias Engdeg=C3=A5rd w= rote: > 27 dec. 2019 kl. 18.07 skrev Pip Cet : > > 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 bee= n debated before. Is there a record of that discussion anywhere? It was part of the rather extensive eq-vs-eql debate, I'm afraid. 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. 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: (defun my-not-eq (x y) (not (eq x y))) (defun always-t () (or (eq 18446744073709551616 18446744073709551616) (my-not-eq 18446744073709551616 18446744073709551616))) (byte-compile 'always-t) (always-t) will yield unexpected results. > > 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 =3D > > 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 l= imit on permissible optimisations? 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. Technically, I think code such as (cond ((eq a b) 1) ((not (eq a b)) 2) (t 3)) is allowed to return 3. We should attempt not to make changes that make this more likely, though. (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?) > 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, de= spite 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 t= he 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. 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. > > 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 b= ecause it's a small thing to do; what I thought looked like an obvious over= sight, or one that made more sense back when Elisp didn't have bignums. Well, Elisp has had floats for a while, and bignum constants appear to be nonexistent, so far.