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: Sun, 29 Dec 2019 23:30:32 +0100 Message-ID: <5AF01F8D-A58B-4A03-BFB9-37F53B695655@acm.org> 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=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="19629"; 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 Sun Dec 29 23:31:15 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 1ilh5e-0004ro-4n for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Dec 2019 23:31:14 +0100 Original-Received: from localhost ([::1]:55604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilh5c-00061j-T7 for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Dec 2019 17:31:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57277) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilh5T-00060z-TJ for bug-gnu-emacs@gnu.org; Sun, 29 Dec 2019 17:31:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilh5S-00079R-AR for bug-gnu-emacs@gnu.org; Sun, 29 Dec 2019 17:31:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54345) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilh5R-00078S-U9 for bug-gnu-emacs@gnu.org; Sun, 29 Dec 2019 17:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ilh5R-00067V-RB for bug-gnu-emacs@gnu.org; Sun, 29 Dec 2019 17:31:01 -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: Sun, 29 Dec 2019 22:31: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.157765864423502 (code B ref 38708); Sun, 29 Dec 2019 22:31:01 +0000 Original-Received: (at 38708) by debbugs.gnu.org; 29 Dec 2019 22:30:44 +0000 Original-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 Original-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 Original-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 In-Reply-To: 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-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-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:173914 Archived-At: 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.