Comment by _k9eq | Hacker News Reader

Comment by _k9eq | Hacker News Reader

I loath these and related libraries. They promote a style that diverges from regular Emacs Lisp code that makes it hard to read if you are not familiar with the additional language, and on top of that frequently promote a wasteful and inefficient style (e.g. instead of searching a buffer it is converted into a string, split on newlines, filtered and then checked if the filtered list is nil). I've sent out numerous patches to remove these leftpad-esque dependencies from projects that often only make use of one or two functions, that more often than not are just alii for built-in functions. Of all these libraries dash has some kind of a legitimation, but all the rest I consider code smell and makes me question if using the package is even worth it.

Also note that (besides dash), emacs-devel decided against adding any of these packages to the ELPAs. This has made it harder to add a number of packages to NonGNU ELPA, but has been a good excuse to get rid of the dependencies. If anyone is looking for some good Elisp exercise consider sending a patch to replace f/s/... with built-in functionality.

In case dash/f/s/... provide functionality that is not available on older releases of Emacs that one still intends to support, consider using compat (https://elpa.gnu.org/packages/compat.html), a library that I have been developing that attempts to backport recent developments for older releases.

When it comes to f and s. Yes. Definitely, I do not want them and I do not need them.

I like dash because it gives me the convenience of threading macros and anaphoric functions. Are there options for those in compat/emacs standard?

Dash is weird because it is both a list library and and bundles macros. Conventional Emacs Lisp does not use anaphoric macros, and to my knowledge the ideomacy their usage is generally contested.

Threading macros and stuff like if-let & co. have been available for a while and are backported by compat.

Most of the time when I am just coding on my personal or small emacs lisp packages I really like the convenience of anaphoric functions.

I have never seen an example of if-let that made me understand it, but I see thread-first and thread-last, those may be useful.

Thanks!

> I have never seen an example of if-let that made me understand it, but I see thread-first and thread-last, those may be useful.

They are often useful when you have a computation that might fail at any step, sort of like with Maybe monads in Haskell. Eg. if I want to retrive a password from auth-source, it might be that no entry exists, or that the entry has no password entry. In that case I do:

    (if-let* ((auth (auth-source-search :host "domain.org"
                                        :create t))
              (func (plist-get (car auth) :secret))
              (pass (funcall func)))
        (use-to-login-to-some-service pass)
      (user-error "Cannot find password"))

Emacs has `thread-first' and `thread-last'.

What is an anaphoric function / macro? I've seen this term floating around and I don't know what it means!

Page 189 of Paul Graham's "On Lisp" [1] introduces for the first time such a function. At least that is what I remember, and also what Wiki [2] seems to say.

[1] http://ep.yimg.com/ty/cdn/paulgraham/onlisp.pdf

[2] https://en.wikipedia.org/wiki/Anaphoric_macro

Neither did I and so I searched for it and got prompted to post this offtopic reply (hopefully interesting for future debates on search engines.)

I looked for anaphoric functions elisp on both DDD and Google. I believe that DDD uses Bing so TL;DR: Bing is not good at searching stuff, only basic queries. After maybe a couple of years of DDD I intuitively knew that I would have had to ask that question to Google.

What is an anaphoric function and why would I want it?

If I remember correctly, these packages are the straw that broke the camel's back on creating NonGNU ELPA. emacs-devel decided against adding these libraries because they are non-idiomatic, and also because they would be polluting the namespace--I recall the emails specifically said that the s-* prefix would not be given up, as it is such a convenient one letter prefix.

NonGNU ELPA was created so that they can alias these packages to something else, and keep using them as dependencies, without giving up the prefixes f-* and s-*.

My biggest problem with most of these libraries is the complete lack of care for efficiency, and some packages use more of these functions than builtins. eg. -map is identical to mapcar (a C primitive), but instead of defining it as a defalias, its defined as a defun that just calls mapcar on its args. Function calls, especially of bytecode, are very slow, so now instead of just a single primitive funcall, there's a second bytecode funcall that does nothing. this is done in a lot of places in dash and especially in s.el. plus, while the compiler will warn when mapcar is called for effect and advise using mapc, it doesn't know about -map, and ive seen it called for effect a lot.

I used to love these libraries coming from a functional programming background, but with more emacs experience I find it hard to decide between using them or the idiomatic elisp.

PRs to correct these dependencies is a great idea, thanks for the tip!

Reply on news.ycombinator.com