Add -comment macro

[licht1stein]

I find the -comment macro to be as usefule in Elisp, as the comment macro is in Clojure. I think it deserves to be part of the dash.el.

[basil-conto]

Thanks.

Any chance we could have some tests in dev/examples.el? Either as a user-visible defexamples in one of the def-example-groups, or as a non-user-visible ert-deftest. I don't have an opinion on which of the two is more appropriate in this case.

[licht1stein]

Hi @basil-conto I have tried adding a test. Thank you!

[licht1stein]

This macro makes development so much quicker and more convenient. I keep defining it in each package and setup I use, and then use it for interactive development. Since I always use dash.el, it would be so great to have it in it.

[licht1stein]

@basil-conto do I need to do anything else for you to merge this? It's a very simple addition, really...

[alphapapa]

I question the value of this macro. In Emacs, it's trivial to comment or uncomment a Lisp form--two keystrokes, at most, which is less than it would take to wrap it in this macro. And commented forms are clearly, visibly commented, so they won't be conflated with uncommented code--while this macro would leave its body appearing as normal, uncommented code, more likely to lead to mistakes.

@licht1stein If you like using this macro in your code, that's great, but I don't think it belongs in this library. Instead you could publish it in a library that you install into your configs so it's always available to you.

[licht1stein]

Thanks @alphapapa I will do as you suggest. However, I would like to point out the value of this macro, the same as it's in Clojure — interactive development.

You can develop within the comment macro, and then keep the code within it for future reference — easy to evaluate and edit. It has a much different merrit, then just commenting code out, and creates a possibility for a much more dynamic workflow.

[alphapapa]

@licht1stein Again, I question the value of that workflow. Keeping old code in non-commented form, inside a macro, amidst code that is actually used, seems like a bad idea to me, because it still appears to be non-commented code. It only acquires the status of being non-executed code when the macro is expanded.

If code retains value for future reference, it can be kept in a comment, in a commit message, or in a separate file (e.g. in my projects, I keep a NOTES.org file for this sort of thing). And even commented code can be evaluated in Emacs, especially if it's on a single line (and if it spans lines, well, Emacs being Emacs, it could easily be extended to evaluate a multiline, commented expression by removing the ;; in a temporary buffer and evaluating it there).

[basil-conto]

The pertinent question is not which workflow is best, as that is clearly subjective. It is clear that -comment provides value to some Elispers.

The question is whether -comment belongs in Dash, a list-processing library that has grown to include various other Clojure constructs that are related to lists only in the loosest of senses. I don't have a strong opinion either way, which is why I was hoping that @magnars or @Fuco1 would chime in.

That said, and FWIW: the most idiomatic analogue of -comment in vanilla Elisp is plain old quote, which maintains the homoiconic benefits of -comment while avoiding the drawbacks of literally commenting out stretches of code.

For example, the following two definitions result in equivalent byte-code:

(defun foo (x)
  (-comment (message ">>> %s" x))
  (if x (1+ x) 0))

(defun bar (x)
  (quote (message ">>> %s" x))
  (if x (1+ x) 0))

BTW, sorry @licht1stein for my slow responses - I'm AFK on and off until November with limited free time, so I can't guarantee how helpful I'll be in maintaining Dash until then.

[magnars]

Personally I am a big fan of the Clojure-esque end-of-file comment-block with code examples for the repl. However, I'm not convinced discussing the merits of different workflows is very relevant here. The question is: Should dash be a list processing library, or an implementation of clojure.core? The inclusion of -> and ->> started this mess. They're so imminently useful that I couldn't stop myself. But I think maybe we should stop there.

As for the comment macro, I just have this in my own emacs.d:

(defmacro comment (&rest ignore))

Couldn't get much simpler than that.

[licht1stein]

The threading macros and other parts of dashade coding in elisp fun for me, thank you for that.

I think that actually turning dash into a port of clojure.core to elisp is not a mess, but something that immensely benefits all the developers and both languages.

But that's my selfish opinion. 😋

[alphapapa]

I think that actually turning dash into a port of clojure.core to elisp is not a mess, but something that immensely benefits all the developers and both languages.

That's an interesting idea, but despite the similarities and inspiration, dash.el is its own thing now. It would be a fine idea to write a new library to actually port Clojure to Elisp; maybe it could be called clojur.el, or cljr.el to be even shorter (having cljr as the symbol prefix).

[licht1stein]

@alphapapa I actually started thinking about that. Having functions that would allow convenient work with hash-maps, for example, would allow for more complex programs to be written easier.

[alphapapa]

@licht1stein Yes, but first see the libraries ht and a, as well as the built-in map and pcase.

[licht1stein]

cljr is already taken by clojure-refactor.

[alphapapa]

cljr is already taken by clojure-refactor.

clj then? cj? I'm sure there's something available...

[licht1stein]

@alphapapa these two look great, thank you!

[licht1stein]

clj.el would be very stylish.