From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] %nil-handling optimization and fixes v1 Date: Thu, 23 Jul 2009 23:38:08 +0200 Message-ID: References: <20090709161043.GA2538@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 1248385148 9201 80.91.229.12 (23 Jul 2009 21:39:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 21:39:08 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jul 23 23:39:01 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 1MU60B-0004l6-Oi for guile-devel@m.gmane.org; Thu, 23 Jul 2009 23:39:00 +0200 Original-Received: from localhost ([127.0.0.1]:59779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU60A-0004dL-VJ for guile-devel@m.gmane.org; Thu, 23 Jul 2009 17:38:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU5zB-0004Bj-DZ for guile-devel@gnu.org; Thu, 23 Jul 2009 17:37:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU5z6-0004At-GJ for guile-devel@gnu.org; Thu, 23 Jul 2009 17:37:56 -0400 Original-Received: from [199.232.76.173] (port=51728 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU5z5-0004Am-Kq for guile-devel@gnu.org; Thu, 23 Jul 2009 17:37:51 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:47993 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MU5z5-0006Ld-8p for guile-devel@gnu.org; Thu, 23 Jul 2009 17:37:51 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C2D3EF9D6; Thu, 23 Jul 2009 17:37:50 -0400 (EDT) Original-Received: from unquote (unknown [81.38.186.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id C54F7F9D5; Thu, 23 Jul 2009 17:37:48 -0400 (EDT) In-Reply-To: <20090709161043.GA2538@fibril.netris.org> (Mark H. Weaver's message of "Thu, 9 Jul 2009 12:11:07 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 125D2AD8-77D1-11DE-AE78-AEF1826986A2-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:8940 Archived-At: Hi Mark, This is also not a patch review yet :) On Thu 09 Jul 2009 18:11, Mark H Weaver writes: > I added the following macros, whose names explicitly state how %nil > should be handled. See the comments in the patch for more information > about these. > > scm_is_false_assume_not_lisp_nil scm_is_true_assume_not_lisp_nil > scm_is_false_and_not_lisp_nil scm_is_true_or_lisp_nil > scm_is_false_or_lisp_nil scm_is_true_and_not_lisp_nil > > scm_is_lisp_false scm_is_lisp_true > > scm_is_null_assume_not_lisp_nil > scm_is_null_and_not_lisp_nil > scm_is_null_or_lisp_nil > > scm_is_bool_and_not_lisp_nil > scm_is_bool_or_lisp_nil These are terrible names. But they seem to be the best names for the concepts we're trying to express. I don't understand all of them yet, will wait for a review -- unless Neil takes care of that before I do ;-) > The following already-existing macros are defined as aliases, such > that their semantics is unchanged (although scm_is_bool used to be a > function and is now a macro). > > scm_is_null --> scm_is_null_and_not_lisp_nil > scm_is_false --> scm_is_false_and_not_lisp_nil > scm_is_true --> scm_is_true_or_lisp_nil > scm_is_bool --> scm_is_bool_and_not_lisp_nil This part sounds right to me, based on the current semantics. > (I still believe that these should be changed to versions that handle > %nil properly, but await approval on that point, so these patches do > not make those changes) Yes, this also sounds right to me. > Also, if the preprocessor macro SCM_ENABLE_ELISP is not true (this > macro already existed and was used in lang.h), all overheads > associated with %nil handling are eliminated from the above macros. Excellent. Hacks like this are excellent :-) > vm-fixes.patch changes semantics, by fixing %nil handling in the > following instructions: br-if, br-if-not, br-if-null, br-if-not-null, > not, not-not, null?, and not-null? Sounds great in principle, though i have not looked at it > srfi-1-fixes.patch changes semantics, by fixing %nil handling in > several functions. Note that this patch (and several other large > forthcoming patches) will be unnecessary if the scm_is_false, > scm_is_true, and scm_is_null macros are changed to handle %nil as I > proposed. Hm. Perhaps we should decide first. > non-essential.patch is the last and least important. It doesn't > change any functionality or implementation. It changes two > occurrences of scm_is_bool and scm_is_null, in which %nil must *not* > be treated as a boolean or null, to use newly-added equivalent macros > which are explicit about how nil should be handled. These changes > will be needed if scm_is_null is changed as I proposed. It also adds > a few comments related to %nil handling. > > I've run "make check" on recent git master (c4b681fd) with these > patches applied, and everything seems to work. Sounds good too. > I haven't yet run any benchmarks, because I'm not sure how to best do > that. I doubt the changes will make any noticeable difference except > possibly in C code which does a lot of tests which include %nil. Yeah I don't expect too many differences either. Still, nice to clean up. Regards, Andy -- http://wingolog.org/