unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: fgallina@gnu.org, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Sweeter Emacs Lisp
Date: Mon, 15 Jul 2013 07:20:07 +0400	[thread overview]
Message-ID: <87r4f0wlug.fsf@yandex.ru> (raw)
In-Reply-To: <m37ggti5lc.fsf@stories.gnus.org> (Lars Magne Ingebrigtsen's message of "Sun, 14 Jul 2013 16:22:39 +0200")

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>   (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.

They're most useful with larger sequences of transformations. You may be
used to reading the code "inside out" by now, but threading operators
are easy to understand, and they make the flow of information much
more obvious.

>>   + 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. 

I'd be willing to bet that Emacs Lisp newcomers originating from other
Lisp backgrounds are a distinct minority.

>>   + 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?

Most of the adopters come from Java and Ruby, AFAIK. And JavaScript,
especially lately.

But, FYI, the first version of Clojure was written in Common Lisp.

I think the OP is missing the point here, though. While the combination
of Lisp-1 and virtual dispatch looks pretty, it's a non-starter for a
Lisp-2, which Emacs Lisp is.

Clojure's standard library is great even without those, for example take
a look at functions dealing with maps:
http://clojure.org/data_structures#Data Structures-Maps (IPersistentMap)

The API is quite dependent on maps being immutable, though, so it
wouldn't be easy to bring them to Emacs either.



  parent reply	other threads:[~2013-07-15  3:20 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 [this message]
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=87r4f0wlug.fsf@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=fgallina@gnu.org \
    --cc=larsi@gnus.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).