From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: emacs lisp syntax rfc: (cond (EXPR => (lambda (X) ...))) Date: Tue, 04 Jan 2011 19:12:21 +0100 Message-ID: <87tyhoa67u.fsf@ambire.localdomain> References: <877hengesr.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1294165071 29790 80.91.229.12 (4 Jan 2011 18:17:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 4 Jan 2011 18:17:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 04 19:17:47 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 1PaBS5-0004qL-UO for ged-emacs-devel@m.gmane.org; Tue, 04 Jan 2011 19:17:46 +0100 Original-Received: from localhost ([127.0.0.1]:43132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaBS5-000740-5i for ged-emacs-devel@m.gmane.org; Tue, 04 Jan 2011 13:17:45 -0500 Original-Received: from [140.186.70.92] (port=46245 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaBRx-00072I-3Z for emacs-devel@gnu.org; Tue, 04 Jan 2011 13:17:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PaBRv-0008FP-ED for emacs-devel@gnu.org; Tue, 04 Jan 2011 13:17:36 -0500 Original-Received: from smtp204.alice.it ([82.57.200.100]:35154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PaBRv-00089m-3s for emacs-devel@gnu.org; Tue, 04 Jan 2011 13:17:35 -0500 Original-Received: from ambire.localdomain (95.244.66.212) by smtp204.alice.it (8.5.124.08) id 4C88E33B0965E8A9 for emacs-devel@gnu.org; Tue, 4 Jan 2011 19:17:33 +0100 Original-Received: from ttn by ambire.localdomain with local (Exim 4.69) (envelope-from ) id 1PaBMr-000546-QP for emacs-devel@gnu.org; Tue, 04 Jan 2011 19:12:21 +0100 In-Reply-To: (Richard Stallman's message of "Mon, 03 Jan 2011 11:15:11 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:134263 Archived-At: () Richard Stallman () Mon, 03 Jan 2011 11:15:11 -0500 It is un-lispy for a special symbol in the middle of a list to change the way that list is used. Hmm. I guess that this is the same grounds for your unease with keyword arguments. Close? My take on the lispiness of this change is: - We are already dealing with a construct where the treatment of the list is non-uniform (EXPR vs BODY), so playing in the "neck" area has precedence: special handling of docstring, =E2=80=98interactive=E2=80=99 form, indentation hints (for =E2=80=98defmacro=E2=80=99), etc. - Functional style is not unlispy. It's true that a large body of Emacs Lisp is written with assignments (and will continue to be done that way), but that is hardly elegant. It would be nice to bolster this argument with "and hardly needed", supplying stats gathered from lisp/* on how often a local variable is declared only to be used in communication between a cond's EXPR and BODY forms, but i haven't done that, yet. (Anyone want to beat me to it?) Having said that, i readily admit my relative inexperience with Lisp (Emacs Lisp or otherwise). It could be that what i hold dear as lispy is actually more schemey than anything... Now for some thoughts on: Here's another syntax that makes it all much simpler. (cond VAR COND-CLAUSES...) [...] The same variable gets used for each clause, but if you want to change to a different one, just write another top-level symbol: (cond tail ((cdr list) (car tail)) first ((car list) (car first))) Really, what i want to do is elide variable names entirely, for what i regard as essentially an internal (to each clause) affair. Any communication outside of that scope is a lose (or rather, is the status quo, which is less than winning). Only the last cond variable gets set, and not if it's nil. So you can also write this: (cond temp first nil ((setq temp (cdr list)) (car temp)) ((setq first (car list)) (car first))) That is more explicit. It is not quite as brief, but it s still better than this: (cond=20 ((cdr list) -> (lambda (temp) (car temp))) ((car list) -> (lambda (first) (car first)))) Currently you can write this, (let (temp first) (cond ((setq temp (cdr list)) (car temp)) ((setq first (car list)) (car first)))) so the alternatives proposed above are not a tremendous improvement, just a small improvement. But even the small improvement might be good, since it improves readability. I should clarify. The original proposal should read: (cond (EXPR =3D> 1-ARY-FUNC) ...) In other words, the (lambda (VAR) ...) does the job, but is not required. So, the example expression you gave above can actually be made even more succinct: (cond=20 ((cdr list) =3D> #'car) ((car list) =3D> #'car) No variables at all!