From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Bug#38708: eq vs eql in byte-compiled code Date: Thu, 2 Jan 2020 00:38:18 -0800 Organization: UCLA Computer Science Department Message-ID: <22304b46-55df-578d-7ce5-97c8b60f684e@cs.ucla.edu> References: <8cd1b5b2-b94e-ce64-0d70-c1b8b012d685@cs.ucla.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------FE470A0E64C82BA217CDD081" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="193124"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Cc: Pip Cet , Emacs developers To: =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 09:39:02 2020 Return-path: Envelope-to: ged-emacs-devel@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 1imw0U-000o6j-AK for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 09:39:02 +0100 Original-Received: from localhost ([::1]:38428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imw0S-0002ky-SP for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 03:39:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42772) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imvzw-0002Io-MX for emacs-devel@gnu.org; Thu, 02 Jan 2020 03:38:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imvzu-0007db-Up for emacs-devel@gnu.org; Thu, 02 Jan 2020 03:38:28 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35850) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1imvzu-0007bl-Ks for emacs-devel@gnu.org; Thu, 02 Jan 2020 03:38:26 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id ED26A160017; Thu, 2 Jan 2020 00:38:19 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UVJ7mBicO-aL; Thu, 2 Jan 2020 00:38:18 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B3DFD160054; Thu, 2 Jan 2020 00:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M-RpE4Mny9MR; Thu, 2 Jan 2020 00:38:18 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7ACC4160017; Thu, 2 Jan 2020 00:38:18 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243855 Archived-At: This is a multi-part message in MIME format. --------------FE470A0E64C82BA217CDD081 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/1/20 4:38 AM, Mattias Engdeg=C3=A5rd wrote: > The flonum/bignum deduplication patch is only in master at this point. = If you think it emacs-27 would benefit from a version of it that specific= ally excludes flonums, this could of course be arranged. This depends on how important we want (eq integer integer) to work in Ema= cs 27 as it did in Emacs 26. If it's important, then we hash-cons bignums in Em= acs 27 (using a patch like the one I just emailed you), and in that case the flonum/bignum deduplication patch does not matter for bignums. If it's no= t important, then I'd say the flonum/bignum deduplication patch is not urge= nt enough to put into Emacs 27. > The standard rule should be not to use 'eq' for numbers of any kind. The manual already says this: To test numbers for numerical equality, you should normally use @code{=3D} instead of non-numeric comparison predicates like @code{eq}, @code{eql} and @code{equal}. > Attached is a proposed documentation patch for emacs-27. While not perf= ect, it should at least be an improvement (and fixes at least one error). I found that a bit too dogmatic about avoiding eq on numbers, as it's rea= sonable to use eq in many cases (I do it in my code, you do it in your code, and = as long as you know what you're doing it's OK). How about the attached patch inst= ead? (It does not assume the global bignum deduplication patch.) >> How about going a bit further, and globally deduplicating all flonums = and >> bignums that result from low-level text-to-number conversion and modul= e imports? >> That conversion is slow and/or rare already, and if we're lucky dedupl= ication >> wouldn't make things noticeably slower and wouldn't be much work. >=20 > Maybe, but wouldn't that slow down reading .elc files (and still not sh= orten individual constant vectors)? Almost surely it would, yes. I don't know how important that would be. Pe= rhaps we'd get performance back elsewhere. Only one way to find out, I suppose.= ... --------------FE470A0E64C82BA217CDD081 Content-Type: text/x-patch; charset=UTF-8; name="doc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="doc.diff" diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi index e952980f26..c8941eab73 100644 --- a/doc/lispref/numbers.texi +++ b/doc/lispref/numbers.texi @@ -39,8 +39,8 @@ Integer Basics Under the hood, though, there are two kinds of integers: smaller ones, called @dfn{fixnums}, and larger ones, called @dfn{bignums}. Some functions in Emacs accept only fixnums. Also, while fixnums can -always be compared for numeric equality with @code{eq}, bignums -require more-heavyweight equality predicates like @code{eql}. +be compared for numeric equality with @code{eq}, bignums require +more-heavyweight equality predicates like @code{eql} and @code{=}. The range of values for bignums is limited by the amount of main memory, by machine characteristics such as the size of the word used diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 4be2eb6918..1c4e7e4d4e 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -266,8 +266,8 @@ Integer Type Bignums can have arbitrary precision. Operations that overflow a fixnum will return a bignum instead. - Fixnums can be compared with @code{eq}, but bignums require -@code{eql} or @code{=}. To test whether an integer is a fixnum or a + All numbers can be compared with @code{eql} or @code{=}; fixnums can +also be compared with @code{eq}. To test whether an integer is a fixnum or a bignum, you can compare it to @code{most-negative-fixnum} and @code{most-positive-fixnum}, or you can use the convenience predicates @code{fixnump} and @code{bignump} on any object. @@ -2167,17 +2167,20 @@ Equality Predicates This function returns @code{t} if @var{object1} and @var{object2} are the same object, and @code{nil} otherwise. -If @var{object1} and @var{object2} are fixnums with the same value, -they are considered to be the same object (i.e., @code{eq} returns -@code{t}). If @var{object1} and @var{object2} are symbols with the +If @var{object1} and @var{object2} are symbols with the same name, they are normally the same object---but see @ref{Creating -Symbols} for exceptions. For other types (e.g., lists, vectors, +Symbols} for exceptions. For other non-numeric types (e.g., lists, vectors, strings), two arguments with the same contents or elements are not necessarily @code{eq} to each other: they are @code{eq} only if they are the same object, meaning that a change in the contents of one will be reflected by the same change in the contents of the other. -For other types of objects whose contents cannot be changed (e.g., -bignums and floats), two arguments with the same contents might or might not be + +If @var{object1} and @var{object2} are numbers with differing types or values, +then they cannot be the same object and @code{eq} returns @code{nil}. +If they are fixnums with the same value, +then they are the same object and @code{eq} returns @code{t}. +If they were computed separately but happen to have the same value +and the same non-fixnum numeric type, then they might or might not be the same object, and @code{eq} returns @code{t} or @code{nil} depending on whether the Lisp interpreter created one object or two. @@ -2188,26 +2191,25 @@ Equality Predicates @end group @group -(eq 456 456) +(eq ?A ?A) @result{} t @end group @group (eq 3.0 3.0) @result{} t @r{or} nil -;; @r{The result is implementation-dependent.} +;; @r{Equal floats may or may not be the same object.} @end group @group -(eq "asdf" "asdf") +(eq (make-string 3 ?A) (make-string 3 ?A)) @result{} nil @end group @group -(eq "" "") - @result{} t -;; @r{This exception occurs because Emacs Lisp} -;; @r{makes just one multibyte empty string, to save space.} +(eq "asdf" "asdf") + @result{} t @r{or} nil +;; @r{Equal string constants or may not be the same object.} @end group @group --------------FE470A0E64C82BA217CDD081--