From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Straight recursive fact prints in floating-point in org-babel but not in REPL Date: Sat, 05 Dec 2015 22:13:01 -0500 Message-ID: <87r3j0uv5u.fsf@pierrot.dokosmarshall.org> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5PlE-0007iu-T4 for emacs-orgmode@gnu.org; Sat, 05 Dec 2015 22:13:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5PlB-00074p-Fp for emacs-orgmode@gnu.org; Sat, 05 Dec 2015 22:13:16 -0500 Received: from plane.gmane.org ([80.91.229.3]:34854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5PlB-00074j-8u for emacs-orgmode@gnu.org; Sat, 05 Dec 2015 22:13:13 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a5Pl9-0007vP-Jx for emacs-orgmode@gnu.org; Sun, 06 Dec 2015 04:13:11 +0100 Received: from pool-74-104-158-160.bstnma.fios.verizon.net ([74.104.158.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Dec 2015 04:13:11 +0100 Received: from ndokos by pool-74-104-158-160.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Dec 2015 04:13:11 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Brian Beckman writes: > Org-babel seems to print SLIME / SBCL bignums as floating point, at least in > this gist (please see > https://gist.github.com/rebcabin/f73cecd3c9b7da6218e9). I'd like to be able > to control whether bignums are printed out in full. Any advice for me? > I think this happens because babel turns result strings into elisp objects, using (read ...). This has two consequences: the string has to be legal emacs-lisp (that causes problems with e.g. scheme evaluators which return things like #t and #f on which the elisp reader chokes; note also the conversion of lisp-vector-to-list in ob-lisp.el which is done to avoid similar problems); it also does violence to some strings as you have observed - e.g. try (read "123456789123456789123456789") 1.2345678912345679e+26 I'm not sure whether the (read ...) is required in order for babel to work correctly, or whether it is a bug. I've wanted to look into this for a while now (ever since Lawrence Bottorff reported the #t problem with scheme), but I have not been able to find any time to do so. -- Nick