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: [PATCH] Clojure-like syntactic sugar for an anonymous function literal Date: Thu, 22 Jan 2015 11:44:34 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1421945085 4819 80.91.229.3 (22 Jan 2015 16:44:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2015 16:44:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Oleh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 22 17:44:45 2015 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 1YEKs8-0004OA-4f for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 17:44:44 +0100 Original-Received: from localhost ([::1]:54747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEKs7-0000G8-FP for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 11:44:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEKs4-0000G0-GP for emacs-devel@gnu.org; Thu, 22 Jan 2015 11:44:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEKs0-0006o6-Jc for emacs-devel@gnu.org; Thu, 22 Jan 2015 11:44:40 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:27384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEKs0-0006o2-FZ for emacs-devel@gnu.org; Thu, 22 Jan 2015 11:44:36 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkPAOwQflSnWBWM/2dsb2JhbABbgweDYFCFCsUdBAICgSQXAQEBAQEBfIQDAQEEIzMjEAsaAhgOAgIUGA0kiFPABpZTAQEBBwIBH4Erj0QHgnWBUwWLAYxUhV2Pc4QChBkhgncBAQE X-IPAS-Result: AmkPAOwQflSnWBWM/2dsb2JhbABbgweDYFCFCsUdBAICgSQXAQEBAQEBfIQDAQEEIzMjEAsaAhgOAgIUGA0kiFPABpZTAQEBBwIBH4Erj0QHgnWBUwWLAYxUhV2Pc4QChBkhgncBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="108478870" Original-Received: from 167-88-21-140.cpe.teksavvy.com (HELO pastel.home) ([167.88.21.140]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2015 11:44:35 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 0C3B52A58; Thu, 22 Jan 2015 11:44:35 -0500 (EST) In-Reply-To: (Oleh's message of "Wed, 21 Jan 2015 22:38:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (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:181621 Archived-At: > #(foo bar) should translate to (short-lambda (foo bar)) Hmm... Not completely sure where I stand on this. A few notes: - I like the generality of CL reader macros. - But extending elisp-mode to understand what's going on (and "do the right thing") with each new reader macro is not easy. So I'm currently against addition of CL style reader macros. In this sense your #(...) proposal is not too bad because the new syntax is largely compatible with what we have already (e.g. the (...) part is parsed in the normal way). - In "(lambda (x) (foo bar))" the main problem for me is the visual length, so I use pretty-symbols-mode to make it look like (=CE=BB (x) (foo bar)). #(foo bar) is still shorter, tho, so I like this. - I'm a functional programmer at heart, so I like making higher-order functions more accessible. - But the current Elisp implementation is not good at handling function calls efficiently, so offering a very short syntax like #(foo bar) is kind of lying to the programmer. - Elisp has the particularity that it's used by a very large number of people who don't actually know/understand the language, and will never really learn it. OT1H (add-hook 'foo-mode-hook #(define-key toto titi)) looks simpler, but OTOH having more equivalent syntaxes leads to more confusion for beginners. So I'm not dead set against it, but I'm not really sure it'd be an improvement either. Of course, your proposal has 2 parts: - the #(...) reader syntax. - the new macro. They work together but can also be used separately. E.g. we could have just the macro and write things like (mapcar (code (+ % 1)) list). And we could have just the #(...) syntax and give it any meaning we like. Stefan