3

The docstring for quote says,

Quoting should be reserved for constants that will never be modified by side-effects, unless you like self-modifying code.

Are there cases in which it is the best choice instead?

Are there any cases in which list should be avoided?


I've asked this question to complement When to use quote for lists? Modifying quoted lists in Elisp, which is mostly about the potential drawbacks of using quote. What I'd like to know is not only when it is ok to use it, but if there are cases in which it is the best choice over list or cons.


PS This question was originally about quote and list, then Dan made me realize I had conflated quote and backquote in my mind. The functions I was actually confused about were backquote and list. Sorry for the confusion.

7
  • Does this answer your question? When to use quote for lists? Modifying quoted lists in Elisp
    – Drew
    Feb 10 at 16:52
  • IMO, general, open questions about when something is better, or what is the best, or what are the pros & cons of XYZ are too broad for this Q&A site, and they solicit discussion or opinion-based answers. A specific how-to or specific conceptual/understanding question is more helpful.
    – Drew
    Feb 10 at 16:54
  • @Drew In my opinion a lot of questions with interesting answers in the network are closed because they're too broad or something like that. My question is not "specific how-to" but I'd say it's rather "specific conceptual/understanding". Feb 10 at 17:00
  • @Drew The question you propose as being a duplicate does not talk about backquote, which is what this question is about.
    – Basil
    Feb 10 at 17:42
  • At this point maybe I should change the title instead of asking another question. Feb 10 at 17:51
4

Are there cases in which [backquote] is the best choice

Yes, when constructing complex list expressions that involve a lot of quoting, unquoting, and splicing. The best example of this is macro bodies. See the example in (info "(elisp) Defining Macros"):

(defmacro t-becomes-nil (variable)
  `(if (eq ,variable t)
       (setq ,variable nil)))

Without backquoting, this would be:

(defmacro t-becomes-nil (variable)
  (list 'if (list 'eq variable t)
        (list 'setq variable nil)))

which is far harder to grok. The problem becomes even more pronounced when splicing (,@) lists in the middle of other lists, as list and cons become insufficient, and append is needed as well.

Are there any cases in which list should be avoided?

TL;DR: No. list and cons are the fundamental building blocks of Elisp, and are implicitly and explicitly used everywhere all the time.

The only reason to prefer backquote over list is for readability.

The only reason to avoid list altogether is when you know for certain that some code, e.g. in a tight loop, doesn't strictly need a freshly allocated cons, and you want to reduce the amount of garbage created for performance reasons. But this is rare and as always should be profiled and analysed carefully.

2
  • Does the suggestion about not modifying quoted lists apply to backquoted ones too? Feb 10 at 14:10
  • 1
    @ArchStanton Depends on its expansion: sometimes it expands to quote, and sometimes to list or similar. Only modify a list constructed with backquote if you're sure it's mutable. See (info "(elisp) Backquote").
    – Basil
    Feb 10 at 14:22
1

Quoted values are established at read-time, and so incur no eval-time cost to build. So there ought to be a slight efficiency benefit to using a quoted value in cases where it's safe to do that.

It it's a genuinely constant value, then quoting is the best choice.

Are there any cases in which list should be avoided?

quote returns the same1 value every time, while list and cons build a new value every time; so obviously don't use list or cons if you're writing code which needs to see the same value each time.

That aside, if you didn't need to create the list at eval-time, then it could potentially be confusing to the reader if you were doing so.


1 For a lisp-based definition of "same".

3
  • The lisp-based definition of "same" baffles me… :-) Feb 10 at 12:48
  • 1
    @ArchStanton It's just a byte-compiler optimisation, similar to read-only char* in C, and well-known compiler optimisations like constant folding, expression elimination, etc.
    – Basil
    Feb 10 at 13:37
  • 1
    Mostly it was a reference to the different kinds of equality in lisp. The value will be eq to the original value, but not necessarily equal if it has been modified in the interim. The classic example being that, over time, the exact same cons cell could represent very different lists.
    – phils
    Feb 10 at 20:48
0

list and quote do not function in the same way. list evaluates its arguments, and quote does not:

(list 1 2 (+ 1 2))                      ; => (1 2 3)
(quote (1 2 (+ 1 2)))                   ; => (1 2 (+ 1 2))
2
  • I forgot to mention backquote! Sorry, I had conflated quote and backquote in my mind. Feb 10 at 12:02
  • Please see the update and the comment to the question. Feb 10 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.