From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: truth of %nil Date: Thu, 02 Jul 2009 23:50:58 +0100 Message-ID: <877hyqk8bx.fsf@arudy.ossau.uklinux.net> References: <87k52uvhnt.fsf@arudy.ossau.uklinux.net> <20090702142823.GA1401@fibril.netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246575120 20939 80.91.229.12 (2 Jul 2009 22:52:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2009 22:52:00 +0000 (UTC) Cc: Andy Wingo , guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 03 00:51:48 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 1MMV87-0003Zf-Az for guile-devel@m.gmane.org; Fri, 03 Jul 2009 00:51:47 +0200 Original-Received: from localhost ([127.0.0.1]:39878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMV86-0008I0-NF for guile-devel@m.gmane.org; Thu, 02 Jul 2009 18:51:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMV83-0008D8-86 for guile-devel@gnu.org; Thu, 02 Jul 2009 18:51:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMV7y-0007zf-4w for guile-devel@gnu.org; Thu, 02 Jul 2009 18:51:42 -0400 Original-Received: from [199.232.76.173] (port=42836 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMV7x-0007z5-Tr for guile-devel@gnu.org; Thu, 02 Jul 2009 18:51:37 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:37777) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MMV7x-0000VF-4X for guile-devel@gnu.org; Thu, 02 Jul 2009 18:51:37 -0400 Original-Received: from arudy (host86-152-99-133.range86-152.btcentralplus.com [86.152.99.133]) by mail3.uklinux.net (Postfix) with ESMTP id 3AC9D1F6AB1; Thu, 2 Jul 2009 23:50:59 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 7F3773801F; Thu, 2 Jul 2009 23:50:58 +0100 (BST) In-Reply-To: <20090702142823.GA1401@fibril.netris.org> (Mark H. Weaver's message of "Thu\, 2 Jul 2009 10\:28\:25 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:8827 Archived-At: Mark H Weaver writes: > I've been considering writing a python compiler for guile. Great! > For python > (and others) there are several values considered to be false, such as > 0 and various empty collections, and so a different approach will have > to be taken to this problem. > > If we want guile to handle many different languages, should we not try > to find an approach to "false-ness" that handles many languages, and > not just a few? There's been loads of prior discussion on this subject. Here are pointers to some of that. http://sourceware.org/ml/guile/1999-07/msg00251.html http://sourceware.org/ml/guile/1998-07/msg00187.html http://lists.gnu.org/archive/html/guile-devel/2001-09/msg00140.html http://lists.gnu.org/archive/html/guile-devel/2001-11/msg00016.html > It seems to me that some code might misbehave in the presence of two > values which are both null? but not eq? to each other. Example? (This seems quite unlikely to me.) > Also, it seems more consistent to use the same strategy for handling > various languages' notions of false-ness. > > To my mind, we should not be changing the data (which only works for > lisp), but rather the constructs that decide whether a given value is > false. > > So how about having elisp `if' and `cond' compile not to scheme `if' > and `cond', but rather to scheme `elisp-if' and `elisp-cond'? Or > perhaps compile `(if c a b)' to `(if (elisp-true? c) a b)'. > > This approach, unlike the %nil approach, will work for other languages > too. Certainly this is a possible approach. In what's been done so far, and what we do in future, I don't think there are any arguments that trump all the other considerations. It's just a matter of balancing performance, robustness, and so on. If more non-Lisp-like languages are added, your consideration of cross-language consistency would gain more weight. On a matter of detail, I don't understand your statement that the current %nil approach won't work for other languages. As the query that started this thread shows, it is perfectly possible to code a new language (VM-Scheme, in this case) in which %nil is true. If I understand it correctly, a key point of the thinking up till now is that Elisp is a special case because it is so `tantalizingly similar' (as Jim put it) to Scheme. This similarity creates the possibility of passing data directly between Elisp and Scheme, and the fact that Guile Scheme treats %nil as both #f and '() follows from that; otherwise it would be necessary to convert data as it passes from one language to the other. In other words - a performance point. Now we have Brainfuck and ECMAScript too, but I don't know if they are complex enough to cast significant doubt on the existing balance. (To be honest, I'm not sure if that's true for ECMAScript, I need to look at Andy's code.) 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? > 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. > On Mon, Jun 29, 2009 at 10:44:54PM +0100, Neil Jerram wrote: >> Seems wrong to me. In Scheme #f should be the only false value. >> What's the argument for %nil being false in Scheme code? (Just for the record, my statement here was wrong, and I've since corrected it.) Regards, Neil