From: Dmitry Gutov <dgutov@yandex.ru>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: fgallina@gnu.org, Lars Magne Ingebrigtsen <larsi@gnus.org>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: Sweeter Emacs Lisp
Date: Wed, 17 Jul 2013 00:23:29 +0400 [thread overview]
Message-ID: <51E5ABC1.5040002@yandex.ru> (raw)
In-Reply-To: <8738rgtnwn.fsf@uwakimon.sk.tsukuba.ac.jp>
On 15.07.2013 9:03, Stephen J. Turnbull wrote:
> If you find
>
> (defun tag-desc-stripped (tag)
> (upcase (replace-regexp-in-string "[<\\/> ]" "" (car tag))))
>
> hard to read,
This is still a trivial example. And no, now I don't, having spent a
couple of years or so writing Elisp. But I still remember that reading
functions "from inside out" was one of the harder parts, especially with
the level of nesting that one can often observe in core Emacs packages.
Look, for example, at `calculate-lisp-indent'.
Here are some appreciative opinions with better examples:
http://blog.8thlight.com/colin-jones/2011/03/27/clojure-mad-science-an-evil-threading-macro-experiment.html
http://debasishg.blogspot.ru/2010/04/thrush-in-clojure.html
http://thecomputersarewinning.com/post/Clojure-Thrush-Operator/
> And this breaks C-x C-e badly.
No more than using local variables, I'd say. Except when you're using
something like `edebug' in dynamic scoping mode (with lexical scoping,
`edebug' doesn't see local vars yet).
> This isn't just a matter of loss of
> convenience; it's a symptom of a major syntax change. It breaks *any*
> code analysis tool.
I don't see how. The analysis tools have to expand macros anyway, or
they would stumble and break when encountering any macro not from a
predefined set.
> And it is unnecessary, except for saving some
> keystrokes. You could imagine
>
> (defun threaded-apply-to-1 (arg &rest list-of-fun)
> ;; actually, just `apply-to' is probably sufficiently mnemonic
> (while list-of-fun
> (setq arg (funcall (pop list-of-fun) arg)))
> arg)
>
> (defun tag-desc-stripped (tag)
> (threaded-apply-to-1 tag
> #'car
> (lambda (x) (replace-regexp-in-string "[<\\/> ]" "" x))
> #'upcase))
>
> That style makes me slightly ill, but (1) it's more general than `->'
> and `->>' combined, and (2) it doesn't turn malformed function calls
> into curried functions implicitly. So it doesn't break C-x C-e and
> other tools that depend on the simplicity of Lisp expression syntax.
True, that's also an option. Here's an implementation in Clojure[0]:
(defn thrush [a & args]
((apply comp (reverse args)) a))
Incidentally, Clojure has a shorter reader macro for anonymous
functions. Yours would look like this:
#(replace-regexp-in-string "[<\\/> ]" "" %)
And being a Lisp-1, it doesn't need the hash-quotes before the other
arguments.
[0] http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/
next prev parent reply other threads:[~2013-07-16 20:23 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-14 2:22 Sweeter Emacs Lisp fgallina
2013-07-14 11:36 ` Dmitry Gutov
2013-07-14 11:53 ` Vitalie Spinu
2013-07-14 12:38 ` Aurélien Aptel
2013-07-14 13:25 ` Xue Fuqiao
2013-07-14 14:16 ` Pascal J. Bourguignon
2013-07-14 14:22 ` Lars Magne Ingebrigtsen
2013-07-14 16:27 ` Juanma Barranquero
2013-07-14 19:43 ` Lars Magne Ingebrigtsen
2013-07-15 3:20 ` Dmitry Gutov
2013-07-15 5:03 ` Stephen J. Turnbull
2013-07-16 20:23 ` Dmitry Gutov [this message]
2013-07-17 14:04 ` Lars Magne Ingebrigtsen
2013-07-17 15:07 ` Dmitry Gutov
2013-07-16 2:15 ` Miles Bader
2013-07-16 9:12 ` Stefan Monnier
2013-07-14 16:18 ` Josh
2013-07-14 16:30 ` Juanma Barranquero
2013-07-14 17:14 ` Josh
2013-07-14 17:18 ` Juanma Barranquero
2013-07-15 6:05 ` Lars Brinkhoff
2013-07-15 7:04 ` Stefan Monnier
2013-07-15 13:30 ` Bozhidar Batsov
2013-07-16 2:26 ` Miles Bader
2013-07-16 6:08 ` Thien-Thi Nguyen
2013-07-16 14:07 ` Drew Adams
2013-07-16 9:11 ` Stefan Monnier
2013-07-14 17:24 ` Andreas Schwab
2013-07-16 2:13 ` Miles Bader
2013-07-16 6:14 ` Stephen J. Turnbull
2013-07-16 9:07 ` Stefan Monnier
2013-07-16 11:09 ` Juanma Barranquero
2013-07-16 12:25 ` Andreas Schwab
2013-07-16 13:04 ` Thierry Volpiatto
2013-07-16 13:42 ` Juanma Barranquero
2013-07-16 14:38 ` Andreas Schwab
2013-07-16 14:42 ` Juanma Barranquero
2013-07-16 20:57 ` Stefan Monnier
2013-07-22 15:24 ` Stefan Monnier
2013-07-22 16:33 ` Thien-Thi Nguyen
2013-07-22 21:04 ` Stefan Monnier
2013-07-23 4:37 ` Thien-Thi Nguyen
2013-08-10 2:52 ` Stefan Monnier
2013-08-10 10:08 ` Pascal J. Bourguignon
2013-08-10 16:27 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E5ABC1.5040002@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=fgallina@gnu.org \
--cc=larsi@gnus.org \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).