From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Mon, 20 Aug 2018 17:41:38 +0100 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <8e0320d9-e0d0-2b57-57cc-2df4399f133c@cs.ucla.edu> <87lgaio7xd.fsf@tromey.com> <877em1cb0i.fsf@tromey.com> <765767b2-d2e5-a9a6-f724-d58ecf4847bb@cs.ucla.edu> <76081b5d-8c10-0a37-2c97-d4864c0faa80@cs.ucla.edu> <09153aed-361d-4f82-d9ac-b502314769ae@cs.ucla.edu> <861sato21d.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534783201 13268 195.159.176.226 (20 Aug 2018 16:40:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 16:40:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (windows-nt) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 18:39:57 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 1frnDe-0003EA-MC for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 18:39:54 +0200 Original-Received: from localhost ([::1]:48171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frnFj-0002I3-Is for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 12:42:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frnFW-0002Gu-QV for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:41:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frnFT-0004nG-8N for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:41:50 -0400 Original-Received: from [195.159.176.226] (port=56081 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frnFS-0004mY-SB for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:41:47 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1frnDJ-0002rE-Ul for emacs-devel@gnu.org; Mon, 20 Aug 2018 18:39:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 34 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:tI7fS5BK37Wc4VYy5UFuQ+M4VIg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:228743 Archived-At: On Mon 20 Aug 2018, Paul Eggert wrote: > Andy Moreton wrote: > >> There will always be a performance diffrence between fixnum and bignum >> values, and it may be useful for performance tuning to have a simple way >> to discover where that boundary lies. > > Performance nerds can use 'most-positive-fixnum' and 'most-negative-fixnum' > for that sort of thing. These constants have been there for some time and are > not going away. My objection is to 'bignump' and 'fixnump', which are no more > necessary as primitives than 'negativep' would be. Pip Cet was advocating removal of most-positive-fixnum, and that is what I was objecting to as being too severe. We do not need negativep as we already have other prmitives for testing that property. >> These are used in the tests to ensure that implementation is correct, >> and that values in fixnum range are always represented as fixnums, not >> bignums. How do you propose to test that without these predicates ? > > Tests can use 'most-positive-fixnum' and 'most-negative-fixnum', constants > that tests need to use anyway in order to generate values like (1+ > most-positive-fixnum). So they can survive quite well without 'bignump' and > 'fixnump' as primitives. You have avoided the question. The current codebase assumes that lisp bignum objects only exist for values outside fixnum range. Without fixnump how can tests check that values within fixnum range actually have a fixnum representation ? How can test check that no bignum object is created for a fixnum value ? AndyM