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: emacs lisp syntax rfc: (cond (EXPR => (lambda (X) ...))) Date: Wed, 05 Jan 2011 16:29:30 -0500 Message-ID: References: <877hengesr.fsf@ambire.localdomain> <87tyhoa67u.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1294262986 396 80.91.229.12 (5 Jan 2011 21:29:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 5 Jan 2011 21:29:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 05 22:29:42 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 1PaavM-0007VY-Dh for ged-emacs-devel@m.gmane.org; Wed, 05 Jan 2011 22:29:40 +0100 Original-Received: from localhost ([127.0.0.1]:58249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaavM-0007vw-3l for ged-emacs-devel@m.gmane.org; Wed, 05 Jan 2011 16:29:40 -0500 Original-Received: from [140.186.70.92] (port=45541 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaavF-0007up-NY for emacs-devel@gnu.org; Wed, 05 Jan 2011 16:29:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PaavE-0000F4-Fr for emacs-devel@gnu.org; Wed, 05 Jan 2011 16:29:33 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:35979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PaavE-0000Ey-CH for emacs-devel@gnu.org; Wed, 05 Jan 2011 16:29:32 -0500 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p05LTg8v014276; Wed, 5 Jan 2011 16:29:42 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 1C1EB130519; Wed, 5 Jan 2011 16:29:30 -0500 (EST) In-Reply-To: <87tyhoa67u.fsf@ambire.localdomain> (Thien-Thi Nguyen's message of "Tue, 04 Jan 2011 19:12:21 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3731=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:134303 Archived-At: > - Functional style is not unlispy. It's true that a Agreed, and as a functional programmer (and implementer of functional programming languages) the fact that the proposed cond => thingy is naturally pure is an important aspect. Richard's proposal fails pretty poorly there. 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 (because the value is used in several of the conditions, but not all (and more importantly not the first), so you can't (or don't want to for efficiency reasons) lift it to before the cond, yet you do want to share it between branches). An alternative would be to add a way for a cond test to add a variable so it's available to the cond's body and to subsequent branches, i.e. a let in the middle of the cond. (cond (foo bar) ((special-let ((var exp1)) exp2) bla... exp1 ...bla) (bli... exp1 ...bli) ...) Such a thing could still be pure, while providing more flexibility than Richard's (since the var doesn't have to take the value returned as the condition, but can take the value of any sub-expression needed to compute that condition). Stefan