When/why should I use progn?

Question

I have seen progn being used quite a lot as I browse the configuration files of experienced Emacs users. I found this nice explanation of progn, but what I am really curious about is, what is the benefit of using this function? Take for example this snippet (taken from Sacha Chua's configuration):

(use-package undo-tree
  :defer t
  :ensure t
  :diminish undo-tree-mode
  :config
  (progn
    (global-undo-tree-mode)
    (setq undo-tree-visualizer-timestamps t)
    (setq undo-tree-visualizer-diff t)))

Is there any major difference between the above configuration and this?

(use-package undo-tree
  :defer t
  :ensure t
  :diminish undo-tree-mode
  :config
  (global-undo-tree-mode)
  (setq undo-tree-visualizer-timestamps t)
  (setq undo-tree-visualizer-diff t))

I feel like the first example is somehow cleaner, even though it has more syntax, and my intuition is that there might be some kind of performance boost from using progn, but I am not sure. Thank you for any insights!

In this particular case there is no difference: use-package will wrap a progn around your :config forms if it is missing. Try it out: you can put point at the end of a (use-package ...) and call M-x pp-macroexpand-last-sexp to see how the macro is expanded. You'll see that it is identical for these two examples. — glucas, Dec 03 '15 at 04:23
An example where progn is needed: https://emacs.stackexchange.com/questions/39172/emacs-lisp-let-with-while — npostavs, Mar 03 '18 at 23:58

score 21 · Accepted Answer · edited May 23 '17 at 12:38

21

progn is typically used when dealing with macros. Some macros (use-package is a macro, last I checked) accept only 1 form, where others consume all remaining forms.

progn is used in the former case to turn a sequence of forms into a single form.

In your examples, the first one uses progn and thus there is 1 form after :config. In the second, there are 3 forms. If the use-package macro only expects 1 form following :config, then it will cause an error.

It is worth noting that using progn works in both cases, while omitting it only works if the macro accepts multiple forms. As a result of this, some people prefer to simply always use progn, because it will always work.

edited May 23 '17 at 12:38

Community

1

answered Dec 03 '15 at 04:17

J David Smith

2,675
1
18
27

21

It really has nothing to do with macros. Some functions and macros have a so-called "implicit progn", meaning that they accept any number of sexps as separate arguments and evaluate them in sequence. Others don't, and instead expect/allow only a single argument where you might want to evaluate multiple sexps in sequence. That's all progn does: it lets you provide a single sexp that when evaluated evaluates the sexp args to progn in sequence. Compare (if true (progn a b c)) with (when true a b c). In both cases, a, b, and c are evaluated in sequence. – Drew Dec 03 '15 at 05:40
1

@Drew: which is what I said. "implicit progn" -> "consume all remaining forms". I reached to macros as an example because that covers 99% of use cases and makes for a clear answer. I considered adding a note pointing out that progn isn't just for macros, but I didn't feel it added to the answer. There are other use cases, but they are rather uncommon. – J David Smith Dec 03 '15 at 05:42
2

use-package allows multiple forms in :config and :init. – Dec 03 '15 at 11:06
8

I disagree that 99% of the use cases are for macros etc. Any function or macro can be passed a progn sexp that contains multiple sexps that are evaluated for their side effects, before returning the result of the last of these. It really has nothing to do with macros. Macros "as an example" is fine. Giving the impression that progn exists for macros, and that 99% of its use is for macros, is misleading, IMO. progn is about shoveling a sequence of evaluations into a single sexp (to fit a given expected argument), and it is therefore about side effects. – Drew Dec 03 '15 at 14:47
@Drew glad you made that clarification here; anyone reading the accepted answer should read your comments first. – Emacs User Dec 03 '15 at 15:36
@Drew: I can't think of any time I've used progn except for as the input to a macro. Can you give an example of where it'd be used aside from as input to a macro or special form? I don't follow your logic about it being about side effects. – J David Smith Dec 03 '15 at 16:20
5
progn was introduced in Lisp 1.5 (see section The Program Feature), in 1962, long before macros were added to Lisp. The purpose is to sequentially evaluate expressions for their side effects. 2. See progn for how Emacs itself introduces progn to Elisp programmers. See the zap-to-char code for a simple use case.

Drew

Dec 03 '15 at 17:42

1

@Drew: while I understand your point now, I don't believe that's the way to answer this question. Even though that was the original intention, in my experience it is very rarely used in that fashion these days. Most of the examples one will encounter when seeing elisp are of progn to pass multiple forms as a single form. The fact that it originally did this to explicitly order forms for their side-effects is not particularly relevent in emacs lisp, even if it is still relevant in other lisps – J David Smith Dec 03 '15 at 22:40

1

@Drew: as an aside: the ordering of lisp forms is implicit in emacs lisp and the usage for side effects is obvious (by virtue of the fact that otherwise it wouldn't be useful for the main use case in emacs). I don't think that the definition of what progn is accurately depicts what we now use it for – J David Smith Dec 03 '15 at 22:41

3

We can agree to disagree. My point is that progn has nothing whatsoever to do with macros. Its purpose is of course "to pass multiple forms as a single form" (your words) - whether to a function or a macro or a special form, but also to "Eval BODY forms sequentially and return value of last one" (doc string). Now as ever ("these days", indeed!). An ordered evaluation is important only for side effects, obviously. A given use case (macro or not) might or might not care about the evaluation order, but that is irrelevant. And Emacs Lisp is not exceptional in any way in this regard. – Drew Dec 04 '15 at 02:54

Just a note of support forDrew.The macro link is news to me. It's simply to allow multiple forms in just about every use case I have seen. "macros" don't even appear on the radar. – RichieHH Dec 13 '20 at 02:13

Emacs User · Answer 2 · 2015-12-03T16:44:18.187

17

The most important reason for progn is described in the first line of the progn documentation (emphasis added):

progn is a special form that causes each of its arguments to be evaluated in sequence and then returns the value of the last one.

Addendum:

Without progn, sequence is not guaranteed, especially if subsequent expressions are dependent on the side effects or return values of the previous expressions. progn enforces execution sequence the same as textual sequence. Helps to not confuse execution with parsing. This behavior goes back to the fundamentals of lisp control structures and functional programming. Here's an excerpt (emphasis added) from the lisp reference manual:

The built-in control structures are special forms since their subforms are not necessarily evaluated or not evaluated sequentially.

Does progn boost performance?

Parsing performance, no. Execution performance, no. At best it may equal but never magically boost performance.

When is progn used?

...most often inside an unwind-protect, and, or, or in the then-part of an if.

edited Dec 03 '15 at 16:44

answered Dec 03 '15 at 04:15

Emacs User

5,643
18
48

I'm not sure why that's so important. Emacs always evaluates sequentially. – Dec 03 '15 at 11:05
2

@lunaryorn see the updated answer. – Emacs User Dec 03 '15 at 15:30
I'm not sure whether I understand your edit. Naturally there are special forms with a different evaluation order (e.g. if), but the normal evaluation order (e.g. top-level forms, function bodies, etc.) is textual. Sure, to some degree that's an implicit progn, but that's usually not what you use progn for in your own code. – Dec 03 '15 at 15:39
I think the Elisp manual node (elisp) Sequencing which you link says it all. – Basil May 17 '18 at 02:46

score 13 · Answer 3 · answered Feb 15 '16 at 21:01

A better way to understand what progn is is by comparing it to the family: prog1 and prog2. The n or 1 or 2 part of the name stands for the statement from the list whose result you are interested in. In other words, progn will return the result of the last statement it contains, whereas prog1 will return the first, and similar for prog2.

Today this functionality seems a little awkward since we learn to either expect the program to return in the last statement, or to instruct it explicitly what to return. Thus prog1 and prog2 are very seldom used. However, if you think about it, it makes sense, and here is how:

Different programming languages use different strategies to describe their semantics. Lisp family used to be tightly tied to denotational semantics. Without going into much detail, this kind of semantics has particular difficulty with something we grew to know as "statements", which are not "expressions". Meanings of code are typically thought in terms of function combinations, while a "statement" which cannot be even described as a function (since it doesn't evaluate to anything) is thus difficult to deal with. However, since Lisp permits side-effects, sometimes a programmer would want to use an expression without using its value in a way that it doesn't affect the expression following it. And this is where progX family comes in.

In C-like languages this feature is sometimes known as sequence point (i.e. ; and , for example). progn is as essential to Lisp-like languages as ; is to C-like languages. It is a fundamental feature of the language one cannot easily replace. However, unlike in C-style languages, Lisp tends to build syntactical abstractions by completely hiding the syntax of the lower level. And this perhaps why you don't see progn used all that often, yet it is one of the important building blocks, when it comes to building higher level language abstractions (s.a. macros).

prog1 useful for variable swap! (setq a (prog1 b (setq b a))) — RichieHH, Dec 13 '20 at 02:15

When/why should I use progn?

3 Answers3