From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal Date: Thu, 22 Jan 2015 18:22:13 +0100 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 1421947356 16908 80.91.229.3 (22 Jan 2015 17:22:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2015 17:22:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 22 18:22:35 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 1YELSj-00063d-71 for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 18:22:33 +0100 Original-Received: from localhost ([::1]:55062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YELSi-0007bu-8u for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 12:22:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YELST-0007bp-HP for emacs-devel@gnu.org; Thu, 22 Jan 2015 12:22:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YELSQ-0002WW-8Q for emacs-devel@gnu.org; Thu, 22 Jan 2015 12:22:17 -0500 Original-Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:57514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YELSP-0002WI-Us for emacs-devel@gnu.org; Thu, 22 Jan 2015 12:22:14 -0500 Original-Received: by mail-we0-f179.google.com with SMTP id q59so3052474wes.10 for ; Thu, 22 Jan 2015 09:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UYXuWVA+2Wbsc9zENkO9R2e9Caw4OuX2LYNKfKOI7no=; b=WQ6j+awb/BbrUg7PwH7B0N+k5gkE98Zy4Qnicl+mbciUfTHxp9Qpoal5w0RdOKSJFl 6tFeR6pa75Mmwfr4N+KBYO9xgMOZ/BoVTTqv2kef87CipS1FnGVQ/bsE0HDIFboeWP5n 5GCMSMZHAvxLxiRT3TNfqAEgcOw3oRNihA+9NAbz5UCRspuP/diX/gYmmh2eT71wtIIZ xqahScvCWUXtsNbt0sjoCqDKbKr1J8fAE0qi7vmDq9S1wJFNzLrvF0Z+2O9g5xDuw3ld 3QecTpt56y/osxUHvDIYCOhK5YHobdgLoWqJWyRWc49/GZTcl8+MDUDDreETq8/o9zK3 pFQg== X-Received: by 10.194.60.19 with SMTP id d19mr5127227wjr.48.1421947333364; Thu, 22 Jan 2015 09:22:13 -0800 (PST) Original-Received: by 10.27.137.137 with HTTP; Thu, 22 Jan 2015 09:22:13 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::233 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:181624 Archived-At: >> #(foo bar) should translate to (short-lambda (foo bar)) > > Hmm... > > Not completely sure where I stand on this. Thanks for the consideration in any case. And I'm glad that I asked this, even if it doesn't lead to a change. > 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. This is good to know. What initially pushed me into this was seeing code that uses `dash.el' and not understanding what `dash.el' does, since it provides not just plain functions, but second order functions that control the flow of the program. That meant that I had to learn it whether I wanted to or not, even if I'm not using it in any of my packages. I'm afraid that making CL style macros available to the public would lead to more 3rd party extensions defining control structures used by other 3rd party extensions. My opinion is that only the core should be allowed to do that. Or at least the 3rd party control flow structures should not propagate. But people want sugar, and that's what `dash.el' gives to them. My #(...) could be a quick fix for that. > 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). Am I right in the assumption that only current #(...) syntax is that of #("foo" ...)? Nothing other than propertized strings uses it? > - In "(lambda (x) (foo bar))" the main problem for me is the visual lengt= h, > 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. For some people, removing one set of parens could be more important than shortening `lambda' to `=CE=BB'. I like either way. > - 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. Note that #(foo %) is open to optimizations: it doesn't have to be exactly (lambda (%) (foo %)), it just has to behave like it. I'm not sure if that helps. > - 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. Just to show you that weird things are happening either way: (defun projectile-unixy-system-p () "Check to see if unixy text utilities are installed." (--all? (executable-find it) '("grep" "cut" "uniq"))) Here's the implementation of `--all?'. It did not make sense to me until I've spent an hour figuring it out. (defmacro --all? (form list) "Anaphoric form of `-all?'." (declare (debug (form form))) (let ((a (make-symbol "all"))) `(let ((,a t)) (--each-while ,list ,a (setq ,a ,form)) (---truthy? ,a)))) Here's the 100% equivalent implementation of `--all?': (defmacro --all? (form list) "Anaphoric form of `-all?'." (declare (debug (form form))) `(cl-every (lambda (it) ,form) ,list)) Here's how `projectile-unixy-system-p' could be implemented with the new reader macro: (defun projectile-unixy-system-p () "Check to see if unixy text utilities are installed." (cl-every #(executable-find %) '("grep" "cut" "uniq"))) 2 chars longer than the impl. with `dash', 1 char shorter if `every' was used in place of `cl-every'. I just want 3rd party packages to use the core Emacs more, so that they are easier to read. > 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. You're right on this one. Let me just recall the point of familiarity: there's a lot of Clojure programmers coming to Emacs, thanks to CIDER.