From unknown Fri Jun 20 07:11:50 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#38708 <38708@debbugs.gnu.org> To: bug#38708 <38708@debbugs.gnu.org> Subject: Status: [PATCH] Deduplicate flonum and bignum constants in bytecode Reply-To: bug#38708 <38708@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:11:50 +0000 retitle 38708 [PATCH] Deduplicate flonum and bignum constants in bytecode reassign 38708 emacs submitter 38708 Mattias Engdeg=C3=A5rd severity 38708 normal tag 38708 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 22 12:10:20 2019 Received: (at submit) by debbugs.gnu.org; 22 Dec 2019 17:10:20 +0000 Received: from localhost ([127.0.0.1]:50182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ij4kG-0001c4-1N for submit@debbugs.gnu.org; Sun, 22 Dec 2019 12:10:20 -0500 Received: from lists.gnu.org ([209.51.188.17]:47817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ij4kE-0001bv-PH for submit@debbugs.gnu.org; Sun, 22 Dec 2019 12:10:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54291) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ij4kD-0001LS-Fq for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2019 12:10:18 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_50,KHOP_HELO_FCRDNS, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ij4kB-0004Qp-IW for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2019 12:10:17 -0500 Received: from mail1461c50.megamailservers.eu ([91.136.14.61]:39300 helo=mail267c50.megamailservers.eu) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ij4kA-0004GQ-RK for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2019 12:10:15 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1577032973; bh=0o2Pi3FbnjGqxKS6oNdkN++eT9dyFi9L4Qza93RWA1s=; h=From:Subject:Date:To:From; b=sQ/1/wUk0fE9zgBXVdPsYRxmQn3UY4XcxldiUBi+o61GXn03KI341jK4vLmkP9x+q 0j/f0apPbZTgrh7ZmS/iXdTLOthmes4J0hsxlNsWlRaq6TNeA4TagR3BrmpNOAfn9M PntsrOATodMcB2CIriuF14ElfpuersGJS4R5CXKI= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail267c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id xBMGgp5n029957 for ; Sun, 22 Dec 2019 16:42:53 +0000 From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: multipart/mixed; boundary="Apple-Mail=_B265F063-E22A-4E8F-9A93-8DD711029456" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: [PATCH] Deduplicate flonum and bignum constants in bytecode Message-Id: Date: Sun, 22 Dec 2019 17:42:50 +0100 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B020E.5DFF9D0D.000E, 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-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=OY7m8SbY c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=M51BFTxLslgA:10 a=mE8gq1b1v8SMOlwpS_UA:9 a=CjuIK1q_8ugA:10 a=W5df0rz_QW9IkWv8V2MA:9 a=B2y7HmGcmWMA:10 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 91.136.14.61 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --Apple-Mail=_B265F063-E22A-4E8F-9A93-8DD711029456 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Minor improvement to avoid duplication of some numbers in bytecode. No significant degradation in compilation speed observed. The savings = aren't huge either: 1382 bytes in all .elc files, but the in-memory = savings are probably higher, since an extra small flonum (1.0, say) only = costs 4 bytes in the .elc file, but something like 16-24 bytes in memory = (pointer + boxed flonum). --Apple-Mail=_B265F063-E22A-4E8F-9A93-8DD711029456 Content-Disposition: attachment; filename=0001-Deduplicate-non-fixnum-numeric-constants-in-byte-com.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Deduplicate-non-fixnum-numeric-constants-in-byte-com.patch" Content-Transfer-Encoding: quoted-printable =46rom=209c2b6e940d9fd6db189c52b92c60ed3a3fb7dfd4=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20= =0ADate:=20Sun,=2022=20Dec=202019=2012:09:06=20+0100=0A= Subject:=20[PATCH]=20Deduplicate=20non-fixnum=20numeric=20constants=20in=20= byte-compilation=0A=0A*=20lisp/emacs-lisp/bytecomp.el=20= (byte-compile-get-constant):=0AUse=20eql=20for=20looking=20up=20= constants=20instead=20of=20eq,=20allowing=0Afor=20bignum=20and=20flonum=20= deduplication.=0A---=0A=20lisp/emacs-lisp/bytecomp.el=20|=202=20+-=0A=20= 1=20file=20changed,=201=20insertion(+),=201=20deletion(-)=0A=0Adiff=20= --git=20a/lisp/emacs-lisp/bytecomp.el=20b/lisp/emacs-lisp/bytecomp.el=0A= index=20118356ec26..60dbae1d4b=20100644=0A---=20= a/lisp/emacs-lisp/bytecomp.el=0A+++=20b/lisp/emacs-lisp/bytecomp.el=0A@@=20= -3462,7=20+3462,7=20@@=20byte-compile-get-constant=0A=20=09=20=20=20=20=20= =20=20(if=20(equal-including-properties=20(car=20elt)=20,const)=0A=20=09=09= =20=20=20(setq=20result=20elt)))=0A=20=09=20=20=20=20=20result)=0A-=09=20= (assq=20,const=20byte-compile-constants))=0A+=09=20(assoc=20,const=20= byte-compile-constants=20#'eql))=0A=20=20=20=20=20=20=20=20(car=20(setq=20= byte-compile-constants=0A=20=09=09=20=20(cons=20(list=20,const)=20= byte-compile-constants)))))=0A=20=0A--=20=0A2.21.0=20(Apple=20Git-122.2)=0A= =0A= --Apple-Mail=_B265F063-E22A-4E8F-9A93-8DD711029456-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 27 09:24:31 2019 Received: (at 38708-done) by debbugs.gnu.org; 27 Dec 2019 14:24:31 +0000 Received: from localhost ([127.0.0.1]:56657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikqXX-0002f9-74 for submit@debbugs.gnu.org; Fri, 27 Dec 2019 09:24:31 -0500 Received: from mail1451c50.megamailservers.eu ([91.136.14.51]:53966 helo=mail266c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikqXU-0002eu-Op for 38708-done@debbugs.gnu.org; Fri, 27 Dec 2019 09:24:30 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1577456662; bh=hgbTq8xnQIi3H5Zdl/CQSO9UIEyHfvLy75txegpgMGg=; h=From:Subject:Date:To:From; b=s2B2HnGf7XnSbvKRHYEPVWWeyJuZBHSMU1+7+9OYGt079IVz6gU5mvokBhVZ1xzO5 e7vuUd740NrcbOpmbRU4xdVFTqVmooNIrxW+8IUuv88a5tb/FxoLNXp2ztIhOu3Dt/ hPRZM2sAbouLVoq1GRCxXBoNHfCLRicheGcHx+Kg= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail266c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id xBREOKiG004240 for <38708-done@debbugs.gnu.org>; Fri, 27 Dec 2019 14:24:22 +0000 From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode Message-Id: Date: Fri, 27 Dec 2019 15:24:20 +0100 To: 38708-done@debbugs.gnu.org X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B0208.5E061416.0020, 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-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=PNJxBsiC c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=3g6p492sQmxEmAzBr6EA:9 a=CjuIK1q_8ugA:10 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 38708-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Pushed to master. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 27 12:07:56 2019 Received: (at 38708) by debbugs.gnu.org; 27 Dec 2019 17:07:56 +0000 Received: from localhost ([127.0.0.1]:57743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikt5g-0006rU-06 for submit@debbugs.gnu.org; Fri, 27 Dec 2019 12:07:56 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:34179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikt5d-0006rB-HV for 38708@debbugs.gnu.org; Fri, 27 Dec 2019 12:07:54 -0500 Received: by mail-oi1-f194.google.com with SMTP id l136so9714026oig.1 for <38708@debbugs.gnu.org>; Fri, 27 Dec 2019 09:07:53 -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=v6HTCHOztvteOsohKokBgGSaxElVjIPmEFPxAk87hXI=; b=ql5RBa71tbUn9jcmfhmp0FJv5IBJfarPq4hQ/lsfVX/AQE7fB0O7kT9kD9OV4WixBU LsTjhtkX80KTNms7JmejOL3Vm1u6q6y9NyZZSNPEwJIV/eZ3EoI653KSTKlcLivuEoL+ MYp5Xs/EX2ldBCVkkrM03urh0p3QkwktJrF9wa+ivqihoW9NdRX6AbBcIItwlRJPfMN4 ybC1uPMOG9/0kSiOVPeGJVnqX8Ua5CPhCJca7N3F4oP4qN2/U2B0mRAZzFz68E1wIcUI iIcfK147AMNEwOuKkfKPbFQJLPJhietFph4mDEnBzqQagy1to9S/6TUQenj9zPkwYugt c9Vg== 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=v6HTCHOztvteOsohKokBgGSaxElVjIPmEFPxAk87hXI=; b=OqlLZwoJWCfVaQu9Re7Rkc5AclAiWofOr+hgP9mKEvmJwTneo3K8uzGnDMLv7Sz6Z7 xwHR7DLy65ud5/8SdLJXjN6QWdDoK3Ty1l6cifE847+ElLTVYKiAfBNihAcBnkpQxyN7 ps7ICYCWXGmPNaIcwBGMvVOAxAdSDq/X4qZn+lqoEqGnDcaK7uRukgPbnNzjj6QB5MoS eyxZdJAXmFJywvHREmqIHh6YNJA+fOY6aAVhC5iZThDKxfQkguELu+KGFKIy0vN/MjrI Mya3Qtr3VBDwQkqzLG0l6b7Mfc03ILWS7ci+CWop6GPu0TGWQLH4jX2512UtY4+iETll OVTQ== X-Gm-Message-State: APjAAAV9pXqPy6pbnpppK2eVb3TllMWUkY7vd/kcWQZK56yqQ+9Y15So b41WB0ofcrZhgVGMSEKZNJkNTUQQPLHTPAFxciM= X-Google-Smtp-Source: APXvYqxvnKFkKWcp8chD+Hg6LM9js0EHHuvJXI0CY9Xa3wfpThCJYykO5lV82gSV0AhAsHdhZJCQ5vU2YtGa/ojXfB8= X-Received: by 2002:a05:6808:208:: with SMTP id l8mr3627003oie.112.1577466467953; Fri, 27 Dec 2019 09:07:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pip Cet Date: Fri, 27 Dec 2019 17:07:11 +0000 Message-ID: Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Dec 22, 2019 at 5:11 PM Mattias Engdeg=C3=A5rd w= rote: > Minor improvement to avoid duplication of some numbers in bytecode. 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). I don't think different floating point representations are still an issue. 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. With your patch, f will return t if it is byte-compiled without optimizations, but nil if it isn't byte-compiled or is byte-compiled with optimizations. > No significant degradation in compilation speed observed. That's good, that was another concern, IIRC. > The savings aren't huge either: 1382 bytes in all .elc files, but the in-= memory savings are probably higher, since an extra small flonum (1.0, say) = only costs 4 bytes in the .elc file, but something like 16-24 bytes in memo= ry (pointer + boxed flonum). I don't see how you end up with 24 bytes in that case, though, unless you over-align floats (which we should, it gives us an extra tag bit). 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 28 10:49:17 2019 Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 15:49:17 +0000 Received: from localhost ([127.0.0.1]:58807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilEL6-0003Xf-Oy for submit@debbugs.gnu.org; Sat, 28 Dec 2019 10:49:16 -0500 Received: from mail1458c50.megamailservers.eu ([91.136.14.58]:40930 helo=mail267c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilEL5-0003XQ-3q for 38708@debbugs.gnu.org; Sat, 28 Dec 2019 10:49:16 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1577548148; bh=GUS/fcK4SSn3UFuEeXXe1b6S5JeLsL323ORJvngI5gw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=XPrvmsX0TQ+0kY9MoMF24KR/WrKwhEyZFDsj3/J4xKYTZg2fitzQyTBt3a+OhOruz lA1xFDDYqBFlA9VNagxdpd4m3wqlQOLAVTTFY5N0RMSDbeLJiKpnpBnr73X/Ynrj4I rPgylO8d+NGCTyAX8g4ZiGbwvb2RXLpwlqPofB60= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail267c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id xBSFn5Eu013911; Sat, 28 Dec 2019 15:49:07 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Sat, 28 Dec 2019 16:49:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> References: To: Pip Cet X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B020C.5E077974.0002, 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-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=OY7m8SbY 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=yVy3ZpRlzR0wyFvDlZgA:9 a=e57Ci6lTW0uizT97:21 a=HehN7hDJsigzIX43:21 a=CjuIK1q_8ugA:10 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 = been debated before. Is there a record of that discussion anywhere? > Most importantly, I think that we should be able to be define >=20 > (defun f () (eq 18446744073709551616 18446744073709551616)) >=20 > 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 = 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 28 11:37:38 2019 Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 16:37:38 +0000 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 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 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) MIME-Version: 1.0 References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> In-Reply-To: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> From: Pip Cet Date: Sat, 28 Dec 2019 16:36:54 +0000 Message-ID: Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 28 13:50:21 2019 Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 18:50:21 +0000 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 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 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 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Sat, 28 Dec 2019 19:50:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> To: Pip Cet 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-Rules: 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-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 28 14:07:41 2019 Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 19:07:41 +0000 Received: from localhost ([127.0.0.1]:58920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilHR7-0008AT-Ic for submit@debbugs.gnu.org; Sat, 28 Dec 2019 14:07:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilHR5-0008AG-Ra for 38708@debbugs.gnu.org; Sat, 28 Dec 2019 14:07:40 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ilHR0-0004nx-H1; Sat, 28 Dec 2019 14:07:34 -0500 Received: from [176.228.60.248] (port=1563 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ilHQz-0001Hm-DW; Sat, 28 Dec 2019 14:07:34 -0500 Date: Sat, 28 Dec 2019 21:07:34 +0200 Message-Id: <83fth4nua1.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-reply-to: (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sat, 28 Dec 2019 19:50:14 +0100) Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Sat, 28 Dec 2019 19:50:14 +0100 > Cc: 38708@debbugs.gnu.org > > 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. IMO, this discussion should happen on emacs-devel, not here. Some people whose opinions might be important don't read the bug list. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 29 12:30:35 2019 Received: (at 38708) by debbugs.gnu.org; 29 Dec 2019 17:30:36 +0000 Received: from localhost ([127.0.0.1]:60169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilcOh-00021r-Ch for submit@debbugs.gnu.org; Sun, 29 Dec 2019 12:30:35 -0500 Received: from mail-ot1-f53.google.com ([209.85.210.53]:39339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilcOf-0001wL-Qj for 38708@debbugs.gnu.org; Sun, 29 Dec 2019 12:30:34 -0500 Received: by mail-ot1-f53.google.com with SMTP id 77so43292769oty.6 for <38708@debbugs.gnu.org>; Sun, 29 Dec 2019 09:30:33 -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=dtroDKZAklyDwCPitbzIGOVb7KNIIxpGxLzlCLKiwn4=; b=c28+hiL7w8QeKWxsmAfW+Uf7OoRaNvIxw8YdginWa2Q5vkMcSMhcTfqd+bFR+Co84B K5pjisNIGifrlr/XsVRyHqVvuI2xqlZkJeP4xThRHDp7F2qnelHduc7hVjfq3IVFwcEC Hx5KVNjCBelS6/8Vqw3aBUQTTJ8V5KSXBDCiwjImlfoSDu14C5Y0JlS7dMSvEluWXsQL YCu4XEUOfPeQttaHudPEw4X6xnOP7TrMPdC8a0ylqhVj2WVTa+Kcv/ZQnPWI87L1rdcM OcrrGCmmJMWkNvdRoZxDi2tIWBAbf1hbDWNhcATwvoLp2nWQRhlh9PDvDaPNKxoMSWBv y+8w== 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=dtroDKZAklyDwCPitbzIGOVb7KNIIxpGxLzlCLKiwn4=; b=ZrF/eRCqUHNWx35Gx/mE3uOLSmByGRXp3Um61geU9jAyaQA3izUf4rh0Rc5eyMQkdl CoYfqC3tF77J6uEsVTBYMOgBmmYbaRAa8VmaRogtdSVA2tMYisG7eJ3e6gNYTmSfy0Y8 zjhkOV3BwUmDYI8ELZeB0dY5d7mpSK/JxX2aXg1FrH87GC1Y08BARCZZKimldK4QOHHs QThKigj0LJqPeNoeSlwtC48uTNAQj4Mokb9TjGVC2sdtQ4i288HwleyFC8W91D0kLe8S 89zqTttluhvZMgbwVnb1aswd3z40GrJQ0mG+7gEs4cZNWq/wz7TM2DCcUWDIha7S//rJ 9+jA== X-Gm-Message-State: APjAAAWZ415m+kCC8a6l8dVvTSk1Q589Ei7niBJoaEAWR1O6fsMeoywx 8GAnLjJbv1SW3V4oW/5dNfBvpoRMubKPdYrQYnM= X-Google-Smtp-Source: APXvYqwV3fZsfHJmb6ZN+tRG3kE9VFFN+/JHpEjtXmUsYzenikqT+exusk7FxjOEatuwgA/mcRWjpv6st6wDm6Kskbw= X-Received: by 2002:a9d:4805:: with SMTP id c5mr33936317otf.292.1577640628211; Sun, 29 Dec 2019 09:30:28 -0800 (PST) MIME-Version: 1.0 References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> In-Reply-To: From: Pip Cet Date: Sun, 29 Dec 2019 17:29:52 +0000 Message-ID: Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Dec 28, 2019 at 6:50 PM Mattias Engdeg=C3=A5rd w= rote: > Elisp has a few 'boundedly undefined' parts which would be avoided in a g= reenfield 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 manua= l. Such as: don't use eq for numbers; don't mutate literals (strings, conse= s, 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). Sorry, the rest of this got a bit long. 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). > In my experience people seem to have little trouble understanding that eq= shouldn't be used to compare numbers. Not my experience. In fact, anyone who reads https://www.gnu.org/software/emacs/manual/html_mono/elisp.html#Equality-Pre= dicates 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)." And there's plenty of code that uses eq to compare numbers, on the master branch, today. So whether you learn by experience or by "stable" documentation, you'll pick up the habit of comparing integers with eq. > 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 in= tegers but not floating-point numbers. Now, the rules are simpler. (Charact= ers still get a free pass, I suppose.) 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"? > While we could document a safe range of fixnums for which eq applies, it'= s probably better not to. My impression was people were very careful to use eq and EQ whenever they could prove the numbers were still in fixnum range. > > 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. > > Given the state of elisp byte-code optimisation, there is plenty of room = for improvements before such semantics become unavoidable. In particular, t= he committed change does not in any way enable such paradoxical behaviour. (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. (You're right about hash tables). > > 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! 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. > >> What would anyone gain from such a restriction? And the change is mino= r because it's a small thing to do; what I thought looked like an obvious o= versight, 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. > > In other words, there is no broken bignum code that can break. Sorry, that was a response to the second part: the original code makes just as much sense now as it did in the pre-bignum age. You're right that folding floats but not bignums is probably a bad idea. This probably isn't leading anywhere, but I still think this snippet of code is somewhat realistic and should never output "1 nil". First we count the number of eq-distinct elements, then we check whether the elements are eq-distinct. (defun count-distinct-elements (&rest args) (let ((ht (make-hash-table :test 'eq))) (dolist (arg args) (puthash arg 1 ht)) (hash-table-count ht))) (defmacro f (x y) `(format "%S %S" (count-distinct-elements ,x ,y) (eq ,x ,y))) (defun g () (f 1.0 1.0)) From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 29 17:30:44 2019 Received: (at 38708) by debbugs.gnu.org; 29 Dec 2019 22:30:44 +0000 Received: from localhost ([127.0.0.1]:60318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilh5A-00066z-Ep for submit@debbugs.gnu.org; Sun, 29 Dec 2019 17:30:44 -0500 Received: from mail1434c50.megamailservers.eu ([91.136.14.34]:39334 helo=mail263c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilh58-00066j-D2 for 38708@debbugs.gnu.org; Sun, 29 Dec 2019 17:30:43 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1577658635; bh=YrLWhPWe7UWKLbD6z8bXYupfINH4eFFPfwAau0E2nt8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=a6BxT5Pkg+d4lKNus1qP0yMEW+u9P0/It7XLK2DGVtYRnQAsG0kK/VwnZCcfPkJfs dnozCdj2JMnL71M/pqh2fqtebnBOJJh9MyYHzUO+ExWVern0jIemHOE7G83eU5d9VM BAraGwq5OmCh/Vqp/AEJDuNbDZyoK/JdM6b6chFw= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail263c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id xBTMUXAG021565; Sun, 29 Dec 2019 22:30:34 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Sun, 29 Dec 2019 23:30:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5AF01F8D-A58B-4A03-BFB9-37F53B695655@acm.org> References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> To: Pip Cet X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B0212.5E09290B.000A, 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-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=II989TnG c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=M51BFTxLslgA:10 a=pGLkceISAAAA:8 a=N54-gffFAAAA:8 a=mDV3o1hIAAAA:8 a=cu4NddDYnOefzFhDVWQA:9 a=QEXdDO2ut3YA:10 a=ZtS5iRB0_bAA:10 a=RLTxASez9csA:10 a=6l0D2HzqY3Epnrm8mE3f:22 a=_FVE-zBwftR9WsbkzFJk:22 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 29 dec. 2019 kl. 18.29 skrev Pip Cet : > On Sat, Dec 28, 2019 at 6:50 PM Mattias Engdeg=C3=A5rd = 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. >=20 > 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=3Deql 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. >=20 > 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-Pr= edicates > 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=E2=89=A0eql. 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)))) >=20 > 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! >=20 > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 30 10:46:50 2019 Received: (at 38708) by debbugs.gnu.org; 30 Dec 2019 15:46:50 +0000 Received: from localhost ([127.0.0.1]:33253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilxFp-0003Vr-Sp for submit@debbugs.gnu.org; Mon, 30 Dec 2019 10:46:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilxFo-0003Ve-4U for 38708@debbugs.gnu.org; Mon, 30 Dec 2019 10:46:48 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ilxFi-0004YH-V0; Mon, 30 Dec 2019 10:46:42 -0500 Received: from [176.228.60.248] (port=1444 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ilxFi-0007Mr-EH; Mon, 30 Dec 2019 10:46:42 -0500 Date: Mon, 30 Dec 2019 17:46:50 +0200 Message-Id: <83d0c5n7dh.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-reply-to: <5AF01F8D-A58B-4A03-BFB9-37F53B695655@acm.org> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sun, 29 Dec 2019 23:30:32 +0100) Subject: Re: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode References: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> <5AF01F8D-A58B-4A03-BFB9-37F53B695655@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38708 Cc: 38708@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Sun, 29 Dec 2019 23:30:32 +0100 > Cc: 38708@debbugs.gnu.org > > Thanks for clarifying. I'll try to be brief; we seem to agree on the important points. PLEASE take this discussion to emacs-devel. These are serious matters, they shouldn't be discussed on the bug list. TIA From unknown Fri Jun 20 07:11:50 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 28 Jan 2020 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator