[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sweeter Emacs Lisp

From: Stephen J. Turnbull
Subject: Re: Sweeter Emacs Lisp
Date: Mon, 15 Jul 2013 14:03:52 +0900

Dmitry Gutov writes:

 > >>   (defun tag-desc-stripped (tag)
 > >>     (upcase (replace-regexp-in-string "[<\\/> ]" "" (car tag))))

 > >>   (defun tag-desc-strip (tag)
 > >>     (->> (car tag) (replace-regexp-in-string "[<\\/> ]" "") (upcase)))

If you find

    (defun tag-desc-stripped (tag)
      (upcase (replace-regexp-in-string "[<\\/> ]" "" (car tag))))

hard to read, the conventional grind

    (defun tag-desc-stripped (tag)
      (upcase (replace-regexp-in-string "[<\\/> ]"
                                        (car tag))))

makes things pretty obvious (unless the target reader really can't
read Lisp at all).  I don't see a real need based on readability.

And this breaks C-x C-e badly.  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.  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)))

(defun tag-desc-stripped (tag)
  (threaded-apply-to-1 tag
    (lambda (x) (replace-regexp-in-string "[<\\/> ]" "" x))

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]