From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20366 invoked by alias); 19 Jul 2013 00:09:50 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 20328 invoked by uid 89); 19 Jul 2013 00:09:50 -0000 X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO aibo.runbox.com) (91.220.196.211) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 19 Jul 2013 00:09:48 +0000 Received: from [10.9.9.207] (helo=mailfront03.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1UzyGS-0002Ju-Gs; Fri, 19 Jul 2013 02:09:40 +0200 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net ([216.102.199.253] helo=localhost.localdomain) by mailfront03.runbox.com with esmtpsa (uid:757155 ) (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) id 1UzyGL-0003RV-G1; Fri, 19 Jul 2013 02:09:33 +0200 Message-ID: <51E883B7.7090302@bothner.com> Date: Fri, 19 Jul 2013 00:09:00 -0000 From: Per Bothner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jamison Hope CC: kawa@sourceware.org Subject: Re: proposed changes to handling of false and end-of-list References: <51CE82FC.9090209@bothner.com> <16EBEA10-7EC3-48A0-A03B-6C845EEE1F91@theptrgroup.com> In-Reply-To: <16EBEA10-7EC3-48A0-A03B-6C845EEE1F91@theptrgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q3/txt/msg00033.txt.bz2 On 07/05/2013 11:43 AM, Jamison Hope wrote: > How will #!null-terminated lists be printed? I think printing them the same way as LList.Empty-terminated lists: '(3 4 5 . #!null) print as "(3 4 5)". > I presume that you mean the Scheme 'list' function here > [i.e. would construct an LList.Empty-terminated list)], and that the > similarly-named Common Lisp 'LIST' function would be terminated by > nil/#!null/#nil. So, a list created in Lisp code would not > (necessarily) have exact representational equivalence with one created > in Scheme code. Right. Furthermore, note there is an awkwardness with equal?: Should: (equal? '(3 4 5) '(3 4 5 . #!null)) ? I think the answer has to be #f, because (equal? '() #!null) --> #f. > But Scheme would be able to iterate over Lisp lists correctly, as long > as it uses null? to check for the end of list (which is the idiomatic > thing to do anyway): > > (define (mylength lst) > (if (null? lst) > 0 > (+ 1 (mylength (cdr lst))))) Right. > Would LList.Empty evaluate as true or false in Lisp code? Methinks it > would need to be false, if we want to be able to pass Scheme lists to > idiomatic Lisp: > > (defun mylength (list) > (if list > (1+ (mylength (rest list))) > 0)) Probably. Guile ELisp treats '(), #f, and nil as all equal (though not eq). So I assume it treats them all as false. > I would also propose the other obvious optimization, that if the > compiler can determine that the type of the expression c is > any-class-other-than-Boolean, then the generated code can just > be ((c != null) ? e1 : e2). That seems a worthwhile optimization. > I would probably go one further and argue that not only should #!null > be false, so should #!void. I'm reluctant for a couple of reasons. Mainly, Kawa treats #!void as equivalent (though not necessarily eq?) to the result of (values). I.e. #!void is zero values. It is not clear that zero values should be false. I think a zero-length tuple is true. There is also the pragmatic issue in Kawa in that multiple values are represented using the gnu.mapping.Values, so you have to check Values#isEmpty(). Also, Values instances may sometimes be mutable. For example there is the ValueStack class, which extends Values. This is admittedly not very clean, but I think that is an issue for another day. -- --Per Bothner per@bothner.com http://per.bothner.com/