From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: CL package serious deficiencies Date: Fri, 10 Feb 2012 13:24:00 -0500 Message-ID: References: <33271707.post@talk.nabble.com> <87fwemcwlx.fsf@spindle.srvr.nix> <87d39pgdu4.fsf@gnus.org> <8739aiogmw.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1328898251 17950 80.91.229.3 (10 Feb 2012 18:24:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Feb 2012 18:24:11 +0000 (UTC) Cc: Nix , Emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 10 19:24:10 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rvv8i-0002pw-Us for ged-emacs-devel@m.gmane.org; Fri, 10 Feb 2012 19:24:09 +0100 Original-Received: from localhost ([::1]:41733 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvv8h-0006vy-U2 for ged-emacs-devel@m.gmane.org; Fri, 10 Feb 2012 13:24:07 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:40355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvv8c-0006vi-Rq for Emacs-devel@gnu.org; Fri, 10 Feb 2012 13:24:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rvv8b-0001Ps-IA for Emacs-devel@gnu.org; Fri, 10 Feb 2012 13:24:02 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:36066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvv8b-0001Pl-Bf for Emacs-devel@gnu.org; Fri, 10 Feb 2012 13:24:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8IAEtfNU9MCqD0/2dsb2JhbABEhQ+pTn6BCIFyAQEEASMzIwULCQIaAhgOAgIUGA0kiA+nJZF1gS+Hd4JYBQIEBwIdAQMCDAcIBgQIg2QFgn2BFgSISZsPhFo X-IronPort-AV: E=Sophos;i="4.73,397,1325480400"; d="scan'208";a="162517771" Original-Received: from 76-10-160-244.dsl.teksavvy.com (HELO pastel.home) ([76.10.160.244]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Feb 2012 13:24:00 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 3F67B58F68; Fri, 10 Feb 2012 13:24:00 -0500 (EST) In-Reply-To: <8739aiogmw.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 10 Feb 2012 16:24:55 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148449 Archived-At: >> I've used incf occasionally, but don't find it terribly important. > I find it adds readability, since you don't have to see that > "(setq foo (1+ foo))" has the same `foo' both places. No disagreement (I also dislike such duplication, which is why I insist on using (set (make-local-variable 'var) val)), I just don't find it's often enough important (in my experience it's not used that often, and most times it's used, it's used on locally-bound variables with short names). This said, if/when we have `setf', then there's no reason not to have `incf'. >>> `plusp'? >> Never used it. (> n 0) is no shorter than (plusp n) and is just as >> clear, so I really don't see the benefit. > Again, I think it's usually more readable, because (as with `zerop') > it's immediately obvious what the condition is. Especially with longer > parameters: > (plusp (1+ (foo-thing-that-computes-something))) > vs > (> (1+ (foo-thing-that-computes-something)) 0) that's because you write it wrong: (< 0 (1+ (foo-thing-that-computes-something))) aka (< -1 (foo-thing-that-computes-something)) aka (assuming it's integer) (<=3D 0 (foo-thing-that-computes-something)) > I think the `-if' and `-if-not' help with reading comprehension, because > you're signalling in the function name what you mean to do, and you > don't have to read the predicate as thoroughly. And the predicate can > be written clearer, too. If you don't have both forms, the predicate > often tends to look like `(lambda (foo) (not ...))', which makes my > brain hurt. That's just a question of habit, really. [ You might prefer "delete-if (=C2=AC =E2=88=98 pred) list", of course. ] Stefan