From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Harald Hanche-Olsen Newsgroups: gmane.emacs.devel Subject: Re: emacs lisp syntax rfc: (cond (EXPR => (lambda (X) ...))) Date: Wed, 05 Jan 2011 23:40:46 +0100 (CET) Message-ID: <20110105.234046.1611011828799323301.hanche@math.ntnu.no> References: <87tyhoa67u.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1294267267 22313 80.91.229.12 (5 Jan 2011 22:41:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 5 Jan 2011 22:41:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 05 23:41:03 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pac2P-0008Ui-Uj for ged-emacs-devel@m.gmane.org; Wed, 05 Jan 2011 23:41:02 +0100 Original-Received: from localhost ([127.0.0.1]:52195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pac2P-00022C-DH for ged-emacs-devel@m.gmane.org; Wed, 05 Jan 2011 17:41:01 -0500 Original-Received: from [140.186.70.92] (port=48559 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pac2G-00020n-Id for emacs-devel@gnu.org; Wed, 05 Jan 2011 17:40:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pac2F-0004xv-8g for emacs-devel@gnu.org; Wed, 05 Jan 2011 17:40:52 -0500 Original-Received: from anne.math.ntnu.no ([129.241.15.150]:64030) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Pac2E-0004xd-OJ for emacs-devel@gnu.org; Wed, 05 Jan 2011 17:40:51 -0500 Original-Received: (qmail 3641 invoked from network); 5 Jan 2011 22:40:47 -0000 Original-Received: from gauss.math.ntnu.no (HELO localhost) (hanche@129.241.15.102) by anne.math.ntnu.no with ESMTPA; 5 Jan 2011 22:40:47 -0000 In-Reply-To: X-URL: http://www.math.ntnu.no/~hanche/ X-Mailer: Mew version 6.3.50 on Emacs 24.0.50 / Mule 6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134312 Archived-At: [Stefan Monnier (2011-01-05 21:29:30 UTC)] > Yet, Richard's proposal solves another problem as well: > often the value is needed not just for the body of a cond branch, but > also for subsequent branches When I read this, I thought for a moment that you had lost your marbles: For you only get into subsequent branches if the previous conditions were all nil, which is a rather boring value to retain for later use. But then I realized that you are now talking about a way to bind subexpressions of a condition to make it available further in, and that makes sense. Sort of. However, it seems to me that we are now coming up with rather convoluted schemes in which scoping become far from obvious, especially to someone unfamiliar with this particular lisp. Also, I wonder what is so special about cond, anyhow? Surely, you may wish to make subexpressions of the condition in an if, when or unless form available to other parts of the form as well? But we already have that: Any lisp programmer will surely understand the role of blah in (let (blah) (if (foo (setq blah (quux))) (bar blah) (baz blah))) and it seems to me that dressing this construct up in a bunch of extra syntax is just going to muddy the waters and confuse the users. And by the way, the bike shed should be blue for certain. - Harald