From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Floating-point constant folding in Emacs byte compiler Date: Mon, 2 Apr 2018 12:20:31 -0700 Organization: UCLA Computer Science Department Message-ID: <058336f6-1b68-69c5-27ee-13edeb86f636@cs.ucla.edu> References: <2ce39e5c-cd1b-65d6-b125-719caad67932@cs.ucla.edu> <83vadmgfbz.fsf@gnu.org> <87d0zr2n1u.fsf@gmail.com> <83h8p2g99p.fsf@gnu.org> <87370m3k4y.fsf@gmail.com> <838taeg6z5.fsf@gnu.org> <7a49cbdf-f2c3-0803-2ee8-3d9f55e405a5@cs.ucla.edu> <7a4f10ec-c1b9-953d-7a95-b2f1ff762735@cs.ucla.edu> <83y3i568i0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------92B416AC7C1282DF4CEA5956" X-Trace: blaine.gmane.org 1522696768 15613 195.159.176.226 (2 Apr 2018 19:19:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Apr 2018 19:19:28 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 02 21:19:23 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f34zD-0003lN-BT for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2018 21:19:23 +0200 Original-Received: from localhost ([::1]:57335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3518-0003um-Q5 for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2018 15:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f350P-0003uR-Mp for emacs-devel@gnu.org; Mon, 02 Apr 2018 15:20:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f350M-0000Wj-GL for emacs-devel@gnu.org; Mon, 02 Apr 2018 15:20:37 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51766) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f350M-0000WG-0A for emacs-devel@gnu.org; Mon, 02 Apr 2018 15:20:34 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9C112161725 for ; Mon, 2 Apr 2018 12:20:32 -0700 (PDT) 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 dwCJyPb7rQc5 for ; Mon, 2 Apr 2018 12:20:31 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C66B8161729 for ; Mon, 2 Apr 2018 12:20:31 -0700 (PDT) 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 wksflchVLvch for ; Mon, 2 Apr 2018 12:20:31 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AA712161725 for ; Mon, 2 Apr 2018 12:20:31 -0700 (PDT) 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.21 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:224253 Archived-At: This is a multi-part message in MIME format. --------------92B416AC7C1282DF4CEA5956 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 04/02/2018 07:48 AM, Stefan Monnier wrote: > we're not free to > merge two strings just because they're `equal`, whereas for floats > we are. Yes, that's the key point here. I see that the Elisp documentation does not specify how eq behaves on floats with the same values, so I took a crack at specifying this the same way that Common Lisp and Scheme do by installing the attached into master. I doubt whether Common Lisp/Scheme semantics here will break real Elisp code in any significant way. --------------92B416AC7C1282DF4CEA5956 Content-Type: text/x-patch; name="0001-Clarify-eq-on-floats.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Clarify-eq-on-floats.patch" >From b89189f686a599817d8cdcc81038b62a38a7baa7 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 2 Apr 2018 12:19:00 -0700 Subject: [PATCH] Clarify eq on floats * doc/lispref/objects.texi (Equality Predicates): Say that two floats with the same values might or might not be eq. --- doc/lispref/objects.texi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index af740625ad..78a7dccc88 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2083,6 +2083,10 @@ Equality Predicates 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., +floats), two arguments with the same contents 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. @example @group @@ -2095,6 +2099,12 @@ Equality Predicates @result{} t @end group +@group +(eq 3.0 3.0) + @result{} t @r{or} nil +;; @r{The result is implementation-dependent.} +@end group + @group (eq "asdf" "asdf") @result{} nil -- 2.14.3 --------------92B416AC7C1282DF4CEA5956--