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: Sweeter Emacs Lisp Date: Mon, 22 Jul 2013 11:24:13 -0400 Message-ID: References: <8738rh6ftk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374507033 6696 80.91.229.3 (22 Jul 2013 15:30:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jul 2013 15:30:33 +0000 (UTC) Cc: emacs-devel To: fgallina@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 22 17:30:33 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V1I4G-0008NH-O2 for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 17:30:32 +0200 Original-Received: from localhost ([::1]:52053 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1I4G-0007DJ-96 for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 11:30:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1I4C-0007Cq-DC for emacs-devel@gnu.org; Mon, 22 Jul 2013 11:30:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1I4A-00008x-R0 for emacs-devel@gnu.org; Mon, 22 Jul 2013 11:30:28 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:62616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1HyA-0005ls-JD; Mon, 22 Jul 2013 11:24:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFG4rw7r/2dsb2JhbAA7Cb8OF3OCHwEFJy8jEAs0EhQYDYhIwS2NFkuDKQOkeoFegxM X-IPAS-Result: Av4EABK/CFG4rw7r/2dsb2JhbAA7Cb8OF3OCHwEFJy8jEAs0EhQYDYhIwS2NFkuDKQOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208,217";a="19525796" Original-Received: from 184-175-14-235.dsl.teksavvy.com (HELO pastel.home) ([184.175.14.235]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 Jul 2013 11:24:07 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 63D9B6D694; Mon, 22 Jul 2013 11:24:13 -0400 (EDT) In-Reply-To: <8738rh6ftk.fsf@gnu.org> (fgallina@gnu.org's message of "Sat, 13 Jul 2013 23:22:31 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:162068 Archived-At: > + The *threading* macros "->" and "->>": Feel free to contribute such macros. I probably wouldn't want to call them "->" and "->>". The name should probably include "thread" or "pipe". To make them useful, they should come with good edebug support, which may turn out to be the more tricky part. > + when-let, if-let: As mentioned, `pcase' comes pretty close to `if-let', so I don't feel a strong need for it. OTOH for when-let you'd need something like (pcase (`(and (pred identity) ,) )) which is uglier. So maybe a when-let makes sense, tho I'd prefer a when-let* (which has also been seen under the name let-and, IIRC). > + *we need a built-in core mapcan (could be called mapcat), filter and > sequence concatenation (could be called cat?) function that doesn't > depends on cl-lib*. This is fundamental stuff isn't it? Why is such a > need to require a library for it? The whole point of the big rename and partial rewrite of CL into cl-lib was so that these functions can be used anywhere, thus making it unnecessary to duplicate them into "core" Elisp. > + Destructuring in defun and let: This looks weirder than I thought > because of our (ab)use of parens everywhere, but I feel this is > something brillant to have as part of the core language. For destructuring let we have pcase-let. I have some tentative pcase-lambda but haven't come up with something good enough yet. I'm definitely open to suggestions here. As for including it directly into "core" `defun', and `let', there are some technical issues (mostly linked to bootstrapping and the performance cost especially in interpreted code), but I do want to make pcase patterns more generally available (e.g. making dolist work like pcase-dolist). Stefan