From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Tue, 10 Jul 2018 21:14:52 +0200 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <83bmecy6fx.fsf@gnu.org> <0d3175d8-d996-651e-b221-71978bde3a65@cs.ucla.edu> <87tvpdnzgy.fsf@tromey.com> <4c2a814f-c254-29e5-39cf-11b5f2e5c9c8@cs.ucla.edu> <49d8ba62-c9a5-9203-d882-8e900b441ff3@cs.ucla.edu> <8e0320d9-e0d0-2b57-57cc-2df4399f133c@cs.ucla.edu> <800714ed-990a-676d-e68c-e6c6bcd72c57@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1531249994 15582 195.159.176.226 (10 Jul 2018 19:13:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jul 2018 19:13:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 10 21:13:10 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 1fcy4U-0003xe-Cc for ged-emacs-devel@m.gmane.org; Tue, 10 Jul 2018 21:13:10 +0200 Original-Received: from localhost ([::1]:49448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcy6b-00019G-6m for ged-emacs-devel@m.gmane.org; Tue, 10 Jul 2018 15:15:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcy6U-00017S-Lc for emacs-devel@gnu.org; Tue, 10 Jul 2018 15:15:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcy6Q-0003VV-Qp for emacs-devel@gnu.org; Tue, 10 Jul 2018 15:15:14 -0400 Original-Received: from [195.159.176.226] (port=50911 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fcy6Q-0003TY-JC for emacs-devel@gnu.org; Tue, 10 Jul 2018 15:15:10 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fcy4B-0003ZC-38 for emacs-devel@gnu.org; Tue, 10 Jul 2018 21:12:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:iJu7GVUg9HdhhReX6uX10yoAwzw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] 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:227223 Archived-At: On Tue, Jul 10 2018, Paul Eggert wrote: >> Some important functions only for fixnums but not for bignums. >> E.g. goto-char or aref. > > Both of these functions have limits that are not relevant to fixnums; > they have limits based on something else. For example, goto-char is > limited to point-min..point-max, and aref is limited to > 0..length-1. We will want both functions to work on bignums, since we > will want to allow buffer sizes and bool vector lengths that do not > fit into fixnums. Speak for yourself. I certainly don't want goto-char or aref to work on bignums. I bed 200 dollars that Emacs will not support buffer sizes or array lengths beyond most-positive-fixnum within the next year. And I would be surprised if Emacs would switch to bignums for functions like, current-time of file-attributes, where it would actually make sense to use bignums. > And even if these functions' limits were relevant to fixnums, I don't > see why one would want to specialize a method just for fixnums as > opposed to settling for specializing it to integers. The method would > accept an integer, and then if it used a fixnum-only goto-char or aref > that would signal an error, just as it would for any other > out-of-range integer. There would be no need to specialize the method > to fixnums. If we follow that argumentation, then no method would ever need any specialization. The method would accept any type and then if something doesn't work for the actual type it would signal an error. > So I'm still not seeing the actual use cases that would suggest that > (type-of 5) should not continue to return 'integer'. To write reasonable programs, programmers need to have reasonable models of how computers work and in particular they need to now how data types are physically represented. That's why some programmers want know if a sequence is a list or a vector or if a number is a fixnum, a flonum, or a bignum. Helmut