From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: truth of %nil Date: Fri, 3 Jul 2009 11:32:22 -0400 Message-ID: <20090703153218.GA1382@fibril.netris.org> References: <87k52uvhnt.fsf@arudy.ossau.uklinux.net> <20090702142823.GA1401@fibril.netris.org> <877hyqk8bx.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246635174 3545 80.91.229.12 (3 Jul 2009 15:32:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jul 2009 15:32:54 +0000 (UTC) Cc: guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 03 17:32:47 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MMkkp-0005E5-4V for guile-devel@m.gmane.org; Fri, 03 Jul 2009 17:32:47 +0200 Original-Received: from localhost ([127.0.0.1]:39585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMkko-0005Cb-CG for guile-devel@m.gmane.org; Fri, 03 Jul 2009 11:32:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMkkh-0005CL-3h for guile-devel@gnu.org; Fri, 03 Jul 2009 11:32:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMkkb-0005BA-LO for guile-devel@gnu.org; Fri, 03 Jul 2009 11:32:38 -0400 Original-Received: from [199.232.76.173] (port=50189 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMkkb-0005B4-Fs for guile-devel@gnu.org; Fri, 03 Jul 2009 11:32:33 -0400 Original-Received: from world.peace.net ([204.107.200.8]:41778) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMkkb-0004dc-8F for guile-devel@gnu.org; Fri, 03 Jul 2009 11:32:33 -0400 Original-Received: from localhost ([127.0.0.1] helo=fibril.netris.org ident=hope4) by world.peace.net with esmtp (Exim 4.69) (envelope-from ) id 1MMkkU-0006Vs-ME; Fri, 03 Jul 2009 11:32:27 -0400 Content-Disposition: inline In-Reply-To: <877hyqk8bx.fsf@arudy.ossau.uklinux.net> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8830 Archived-At: Thank you, Neil, for the pointers to earlier discussions of this subject. Having read them, I've been convinced that the %nil approach is reasonable and probably the best way to deal with elisp<->scheme interoperability. Though, like you, I was not willing to easily accept two false values and two end-of-list values :) > Python on the other hand would be plenty complex enough, and I assume > it has arbitrarily complex data structures. How do you envisage data > transfer working between Python and other languages? I'll answer this in a later email. > > It also means that Guile's normal `if' and `cond' won't be slowed down > > by having to check for two values instead of one. That overhead may > > be insignificant now, but when we have a native code compiler, it will > > be quite significant in code size at least, even if the > > representations of %nil and #f differ by only one bit. > > Do you really think so? Just because of two compare operations > instead of one? Perhaps I'm misunderstanding you. A single compare and branch is a very short instruction sequence, especially (on some architectures at least) if the constant being compared is a small number. When there are two values to compare against, that means either two compares and two conditional branches, or, if the two values differ by only one bit, ANDing with a mask before the compare. Either way, the code size increases quite a bit. This price will be paid for every boolean test, and every end-of-list test, which are obviously very common. It might be worth considering a build-time option to disable %nil, so that it's possible to build a version of guile which doesn't pay this price. Best, Mark