Lisp, documenting my encounter with, step #2

29/07/19, modified 30/07/19

Dear blog, yesterday seem to have disappeared in the fog of time without me writing to you, I'm so sorry1. I promised to write a bit about the Special Operator Progn.I have no idea yet why this is called a "Special Operator"2. The writer of the specification was hopelessly confused when writing this one3. First lines;

progn form* => result*

Arguments and Values:

forms---an implicit progn.

results---the values of the forms.

As this will turn out to be important later, I checked the meaning of the asterisk symbol. This is not to be found in the spec as far as I can see, but the author does refer to an((yes the documentation says an, but which one?)) extended BNF, and although the meaning of "extended" is apparently free to interpretation, the asterisk probably stands for 0 or more4.  So, conclusion zero or more forms in, zero or more results out.

Next the description:


progn evaluates forms, in the order in which they are given.

The values of each form but the last are discarded.

The first line parses, the second seem to be in direct contradiction to the "Arguments and Values". Which is it? all the values of all the forms or only the last one? Maybe the examples will make this clear, but first another descriptive line:

If progn appears as a top level form, then all forms within that progn are considered by the compiler to be top level forms.

More links, these have to wait, but this does not parse as is, so if it is a "bottom level form" then all forms are considered "bottom level", or also mid level? or what? What does this mean and how does this  sentence clarify?

On to the examples;

 (progn) =>  NIL
 (progn 1 2 3) =>  3
 (progn (values 1 2 3)) =>  1, 2, 3
 (setq a 1) =>  1
 (if a
      (progn (setq a nil) 'here)
      (progn (setq a t) 'there)) =>  HERE
 a =>  NIL

First line, a special case, not described or obvious5, but at least now we know that zero forms will result in NIL.  Second, confirms to the description. Third, does this help? a single form will result in the result of that single form. Fourth line and fifth, here we go again, completely over the top side issues added, or does this have to do with the "top level" thing? and then how would this be different in a function definition?



Many places in Common Lisp involve syntax that uses implicit progns. That is, part of their syntax allows many forms to be written that are to be evaluated sequentially, discarding the results of all forms but the last and returning the results of the last form. Such places include, but are not limited to, the following: the body of a lambda expression; the bodies of various control and conditional forms (e.g., case, catch, progn, and when).

This was how I got to the progn, the if ((special operator, operator, form, function, macro or whatever)) does not support the "implicit progn".  This is not how you specify a language! So we have here this syntax, sometimes it is used, sometimes it is not used, here is some of the sometimes it is used. So let say you have 10 people in the spec commission, responsible for writing it. You divide all functions, forms and whatnot between those 10, each has to then do about 100 or whatever. For each you list the implicits and not-implicits or not applicables. You get 3 tables6. You put them in.  Done. O wait, you think this "implicit progns" links points to this?

  1. and also I'll end this style of starting an entry! []
  2. another one for the queue []
  3. and this happened to be one of first things I needed!! []
  4. Would it have been so hard to describe the BNF format fully in the specification. Or to at least provide a reference? []
  5. do they know what an example means? []
  6. or there abouts, whatever counting is hard []

6 Responses to “Lisp, documenting my encounter with, step #2”

  1. The name always seemed self-descriptive to me: "progn" programmatically (sequentially) executes a series of statements and returns the evaluation of the Nth (vs. e.g. prog1, where -- the 1st).

    There are many confusable/redundant moving parts in Common Lisp, but I never found this one to be one of them.

  2. ave1 says:

    Stan, I did not have a problem with the name. Although, now that I read your comment, how does Nth mean Last?

    I also see how I can use and would need this 'progn'. And now that you mention prog1, I'll look into that one and prog2.

    I tried to learn lisp by reading books first, i.e. the gigamonkeys one (Could not get trough it, too stupid), "on lisp" (Very bad writing), "... small pieces" (Hmm). I hoped the spec would be just that, a spec.

  3. spyked says:

    IMO the absence of proper Lisp learning material is infuriating. I'm going to have to dig some text myself and review it.

  4. ave1: FWIW I originally learned from Graham's 1994 "red" book ("ANSI Common Lisp"). Found his "On Lisp" to be largely useless, esp. for beginners -- consists mostly of circus tricks.

  5. lispm says:

    A slightly more beginner friendly book was 'Common Lisp, the language', here the second edition : PROGN is here:

    That book was written as the language description, before (CLtL1) and during (CLtL2) the ANSI CL specification work...

  6. [...] remarks the lack of Common Lisp learning material. Jurov recommends CLTL2, while Stan mentions one of [...]

Leave a Reply