From: Lars Magne Ingebrigtsen <larsi@gnus.org>
To: fgallina@gnu.org
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Sweeter Emacs Lisp
Date: Sun, 14 Jul 2013 16:22:39 +0200 [thread overview]
Message-ID: <m37ggti5lc.fsf@stories.gnus.org> (raw)
In-Reply-To: <8738rh6ftk.fsf@gnu.org> (fgallina@gnu.org's message of "Sat, 13 Jul 2013 23:22:31 -0300")
fgallina@gnu.org writes:
> + The *threading* macros "->" and "->>":
[...]
> (setq tag (cons "<p>" "</p>"))
>
> (defun tag-desc (tag)
> (concat (upcase (car tag)) "."))
>
> (defun tag-desc-stripped (tag)
> (upcase (replace-regexp-in-string "[<\\/> ]" "" (car tag))))
>
> ;; with threading macros
> (defun tag-desc (tag)
> (-> (car tag) (upcase) (concat ".")))
>
> (defun tag-desc-strip (tag)
> (->> (car tag) (replace-regexp-in-string "[<\\/> ]" "") (upcase)))
It's not clear what the point of these are. Just to make the code more
obscure and cool? The new forms (as demonstrated here) even leads to
longer code, in addition to being pretty opaque. While the "old" code
is obvious and easy to read.
> + when-let, if-let:
Yes, `when-let' is pretty nice.
> + *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?
Why not just use the cl functions?
> + 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.
Destructuring lambda argument lists (a la Common Lisp) would be very
nice, yes, but is probably an uphill battle.
> ;; let destructuring
> (defun fmt-tag (tag)
> (let (((open close) tag))
> (format open close)))
This is just a different way to write `destructuring-bind', though. I
don't see the point.
> + make `let` work like `let*`: "let's" stop confusing newcomers.
I don't think it's that confusing. It would be more confusing having
let and let* work differently in Emacs Lisp than in other Lisps, I
think.
> + hash-tables: how come that working with hash-tables is such a pain?
> I love how they are function of themselves in clojure and that
> there's reader syntax for them.
>
> (setq tags (make-hash-table))
> (puthash tags :p "</p>")
> (puthash tags :span "</span>")
> (gethash :span tags) ; -> "</p>"
That's painful? It seems clear and nice to me.
> ;; clojuresque version
> (setq tags {:p "</p>" :span "</span>"})
> (:p tags) ; -> "</p>"
> (tags :p) ; -> "</p>"
> (:html tags) ; -> nil
This just seems like a "neat" way to write opaque code. Did the Clojure
people come from a Perl or Scheme background, by any chance?
> [0] http://clojure.org/
If these are the bits that are exciting in Clojure, then Clojure doesn't
seem particularly exciting to me. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
next prev parent reply other threads:[~2013-07-14 14:22 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 [this message]
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
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=m37ggti5lc.fsf@stories.gnus.org \
--to=larsi@gnus.org \
--cc=emacs-devel@gnu.org \
--cc=fgallina@gnu.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).