From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: dancol@dancol.org Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Sat, 21 Apr 2018 19:48:55 -0700 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <83bmecy6fx.fsf@gnu.org> <0d3175d8-d996-651e-b221-71978bde3a65@cs.ucla.edu> <51e619e0-ee38-eb97-6c1d-0925b675290a@disroot.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1524365229 15298 195.159.176.226 (22 Apr 2018 02:47:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Apr 2018 02:47:09 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] Cc: eliz@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 22 04:47:05 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 1fA51q-0003r6-Sx for ged-emacs-devel@m.gmane.org; Sun, 22 Apr 2018 04:47:03 +0200 Original-Received: from localhost ([::1]:42041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fA53x-000448-Pu for ged-emacs-devel@m.gmane.org; Sat, 21 Apr 2018 22:49:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fA53r-00043K-Aj for emacs-devel@gnu.org; Sat, 21 Apr 2018 22:49:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fA53q-00032Z-KO for emacs-devel@gnu.org; Sat, 21 Apr 2018 22:49:07 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54882) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fA53n-0002z0-QZ; Sat, 21 Apr 2018 22:49:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=nB1fpTMQd4z2pzEnzgwY3PABqNpBLZWj98eLVTLuaNc=; b=Lb6gA52yvSu3eLoVhzwtD9wGAZk3ithX44mP2O7npboQBZxHjD5ZoM30kjK6CNxWwrga+hKJTv7jqVxRJRpbkKI55kcAL8psk2xFJpwaz3M3ehl58nYBQSHcgywKBRlKkB23JIj7ciIPliflLUM9no64oYw6HLFPgKroPRzZ/rCPuJ15SNXVnLKaBdtHXM69uSQHiesTa71whCkG9qzCVXh/EQa+31NkknKz7AF+M3wAF9iSfj7sUIcBx+l+cm4rdxHnoSGs0P9c6MfyG5vx8jk3mm1rIdIXSozra6gFiypUDHIDj2sKyABCs9g4kYTY0w9TLT9W3+2GxfC8zCj8rw==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fA53f-0007ZK-9I; Sat, 21 Apr 2018 19:48:55 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Sat, 21 Apr 2018 19:48:55 -0700 In-Reply-To: X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:224780 Archived-At: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > Of course we could to do that. Hopefully there isn't existing > > Emacs Lisp code that relies on unsafe arithmetic /anywhere/. If the > > functions + - * / operate on bignums (instead of dedicated bignum > > functions), would that mean we drop 32/64 bit integers entirely? > > To eliminate the current types for small integers would > require rewriting of much of the C code in Emacs. > It would be better to represent small integers as now, > and have a different structure for larger integers. > I'd love to see Emacs get transparent bigint support. Python semantics are fine, as is using a normal int representation at the C level. Adding transparent bigints as Lisp types doesn't require us to increase various Emacs core limits right away.