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: Sun, 30 Aug 2009 12:07:36 +0100 Message-ID: <87my5hy2yv.fsf@arudy.ossau.uklinux.net> References: <87k52uvhnt.fsf@arudy.ossau.uklinux.net> <873a9hl5uf.fsf@arudy.ossau.uklinux.net> <4A4B0619.5070006@domob.eu> <87ljn8rrv9.fsf@arudy.ossau.uklinux.net> <20090705130725.GA2021@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 1251630477 17362 80.91.229.12 (30 Aug 2009 11:07:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2009 11:07:57 +0000 (UTC) Cc: Andy Wingo , Daniel Kraft , guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Aug 30 13:07:50 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 1MhiGD-0006Sd-Nb for guile-devel@m.gmane.org; Sun, 30 Aug 2009 13:07:50 +0200 Original-Received: from localhost ([127.0.0.1]:56506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhiGC-0002os-RP for guile-devel@m.gmane.org; Sun, 30 Aug 2009 07:07:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MhiG7-0002oV-Pi for guile-devel@gnu.org; Sun, 30 Aug 2009 07:07:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MhiG3-0002nv-VD for guile-devel@gnu.org; Sun, 30 Aug 2009 07:07:43 -0400 Original-Received: from [199.232.76.173] (port=60615 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhiG3-0002nr-Gc for guile-devel@gnu.org; Sun, 30 Aug 2009 07:07:39 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:33433) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MhiG2-0006TR-Qq for guile-devel@gnu.org; Sun, 30 Aug 2009 07:07:39 -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 C6F281F66FB; Sun, 30 Aug 2009 12:07:37 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 12F0138021; Sun, 30 Aug 2009 12:07:37 +0100 (BST) In-Reply-To: <20090705130725.GA2021@fibril.netris.org> (Mark H. Weaver's message of "Sun\, 5 Jul 2009 09\:07\:30 -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:9204 Archived-At: Hi Mark! Mark H Weaver writes: > I would like to argue that the definitions of scm_is_false, > scm_is_true, and scm_is_null should indeed be changed to test for > %nil. OK, thanks to your arguments, I now agree with this. > Do a grep-find in the tree for uses of these macros. I think you'll > find that the majority of places where they are used should also be > checking for %nil, but they are not. I started doing this. Actually some of the first ones are in backtrace.c (testing for the file and line source properties), and I think those may be counter-examples... but I agree that there are many many cases that should be allowing for %nil. But then I thought that this argument isn't really about the numbers. It's that we have effectively taken a decision to treat Elisp as a special case, among the set of languages that Guile may eventually support - a fact which I now realize more clearly thanks to your and others' querying of the treatment of nil, and thanks to the developing language support - specifically in the sense of being able to pass data between Scheme and Elisp without requiring any translation. And therefore it makes sense that libguile's most immediately available APIs - i.e. scm_is_false/true/bool/null - should allow for their args coming from either Scheme or Elisp. So, thanks for persisting with the argument. > If, in a particular use, it > can be proved statically that the value was not created by an elisp > function (which we can almost never prove), then that is a case where > we can use some faster test. But someone will have to think about > each of these cases individually anyway, so it makes sense that these > faster tests should be named something different than the old names, This is of course something that you've included in your patch, and I'm happy with that. This is also something that could (potentially!) be optimized at runtime or by the compiler (reminds me of the class of calls where type checking could be eliminated if the compiler can prove that objects will always be of the required type). So, if you would be happy to do so, can I suggest that you rework your patches so that they also make (and then assume, obviously) the scm_is_false/true/bool/null change, and incorporate my other comments? It would also be more convenient - and better for giving you your deserved attribution - if you could submit them as Git patches. Would that be possible? Alternatively, if you have your own Git repository, we could pull from that. Also, we will need documentation of the new APIs, and to explain the overall concept; and a NEWS entry; and maybe a couple of tests to check where data that includes %nil is passed to some of the fixed functions. Would you be willing to prepare all those too? > One category of place where these could be used is code dealing with > data structures created internally by the evaluator -- though I'm not > very familiar with guile's internals, so I don't know how common these > data structures are, if indeed they exist at all. Yes, indeed. In the updated patch(es), I suggest that you mark the cases that you are not sure about, then I and other developers can help work out what kind of check they should be doing. Many thanks! Neil