From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.lisp.guile.devel Subject: Re: %nil once again Date: Fri, 31 Jul 2009 07:03:09 +0200 Message-ID: <4A727B0D.6080303@domob.eu> References: <4A5F2F8A.5040108@domob.eu> <87ws63md6v.fsf@unknownlamer.org> <87d47hyhoz.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249016602 1226 80.91.229.12 (31 Jul 2009 05:03:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jul 2009 05:03:22 +0000 (UTC) Cc: Clinton Ebadi , Andy Wingo , guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 31 07:02:53 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 1MWkGa-0004L0-VN for guile-devel@m.gmane.org; Fri, 31 Jul 2009 07:02:53 +0200 Original-Received: from localhost ([127.0.0.1]:45412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWkGa-0000f9-8o for guile-devel@m.gmane.org; Fri, 31 Jul 2009 01:02:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWkGX-0000f4-DN for guile-devel@gnu.org; Fri, 31 Jul 2009 01:02:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWkGS-0000es-Fb for guile-devel@gnu.org; Fri, 31 Jul 2009 01:02:48 -0400 Original-Received: from [199.232.76.173] (port=55141 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWkGS-0000ep-Bx for guile-devel@gnu.org; Fri, 31 Jul 2009 01:02:44 -0400 Original-Received: from tatiana.utanet.at ([213.90.36.46]:57393) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MWkGR-0000sd-RR for guile-devel@gnu.org; Fri, 31 Jul 2009 01:02:44 -0400 Original-Received: from paris.xoc.tele2net.at ([213.90.36.7]) by tatiana.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MWkGL-0002tC-NH; Fri, 31 Jul 2009 07:02:37 +0200 Original-Received: from d86-32-16-119.cust.tele2.at ([86.32.16.119] helo=[192.168.1.18]) by paris.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MWkGL-0001Xh-IJ; Fri, 31 Jul 2009 07:02:37 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: <87d47hyhoz.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:8998 Hi Neil, Neil Jerram wrote: >> The only downside I can see to this is that if code were >> to be ported from elisp to Scheme there would now be code that assumed a >> '() return as false when #f would be false, but this could be fixed >> using a predicate like elisp-false? (or null-or-false? or >> ... something). > > I don't like that at all! > > In my view, the only reasonable alternative solution above is the one > that would work by translating data passing between Elisp and Scheme. > The theoretical argument against that is that such translation could > be arbitrarily complex, and so have an unbounded performance cost, but > in practice I imagine that would almost never be the case. Also there > is the point that languages other than Elisp will _require_ data > translation, and why should we make Elisp a special case? Hence I > wouldn't rule out the possibility of switching to this design in > future; and then we could, as you say, make nil==() and remove most > elisp special cases from the libguile core. I agree here; though I think we should get translation to a minimum as much as possible; for instance, I still think the Guile core should treat %nil as false and empty list if asked for. This does not hurt Scheme, as %nil does not occur there, but it would allow us to just use TreeIL conditionals and the like without having to translate here. On the other hand, if we want elisp semantics as faithfully as possible, we need to translate the way from Guile primitives to elisp code. Currently I'm already doing this for booleans; for instance, the = built-in of emacs is defined something like: (lambda (a b) (if (= a b) t %nil)) so that the "false" value is really %nil. On a later thought, this might be the real reason why my "tight while loop" performed worse than the Scheme version in the performance test. But I don't see a way how to get around this, unfortunatly; except if we just assume that the elisp user won't test a false value for (eq value nil) but just use it as boolean in conditionals, too, so it does not matter if the value is %nil or #f. The same applies to lists... In general, one can write probably most elisp code without having to really care if the tail of a rest argument or the result from the list built-in or some quotation-expression is %nil or '() (and should actually check with null instead of (eq nil), I think). At the moment it is like that, there's no '() <--> %nil translation happening by now. As long as libguile/VM gets the patch to accept %nil as end-of-list (as the interpreter already does), one can still do (cons 'a (cons 'b nil)) in elisp and get the expected result... I'm still not sure if we should actually do data translation from Scheme (Guile built-ins) to elisp user code or not... But probably we should just do it and the performance hit will not be too painful. Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri