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!

Answer 1

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.

Answer 2

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.

Answer 3

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).