Background: the nlet macro
'Way back in 1980, when I was an MIT undergraduate hacking on the Lisp Machines at the AI Lab, I was already starting to experiment with a more functional style than most people there used. And one thing I quickly discovered was the usefulness of the multiple-value feature in this style. For example, instead of doing (when (something) (rotatef a b)) to conditionally swap the values of two variables, I found I could do this:
Whether this is really a stylistic improvement or not is certainly debatable, though I still do it, but it does get rid of the assignments.
Of course, the more common use of multiple values is to return more than one piece of information from a function. Some languages have "out parameters" for this purpose, but Common Lisp, like Lisp Machine Lisp before it, has multiple values; and some CL builtins are specified to return multiple values (floor and ceiling come to mind, but there are many others). On most implementations, returning multiple values is much faster than consing up a list or other structure to return, because the semantics don't make the tuple of values a firstclass object (unless, of course, you do that explicitly with multiple-value-list). Instead, like arguments to a call, they are generally returned in registers or on the stack.
Anyway, as I was making fairly frequent use of multiple-value-bind, sometimes nesting two or three such forms together, it seemed to me that I should be able to write them similarly to let forms — that the difference between binding one variable and binding two or more was not so large that I should have to use a completely different construct for the latter. Also, I noticed that there was space in the syntax of let to extend it: let's binding clauses are specified to be lists of length two (or one, but let's ignore this case), of which the first is the variable to bind and the second is the init-form whose value is to be bound to. The obvious generalization is that all subforms of the clause but the last are variables to be bound, and the last subform is the init-form that will supply those values.
It also occurred to me, as I was using both let for parallel binding and let* for sequential binding, that there was a way to allow arbitrary combinations of parallel and sequential binding using clause nesting: nesting an inner clause inside an outer one would make the variables bound by the outer one available to the inner one.
Thus was born my macro nlet. Here's an example:
(nlet ((a b c (zot))
((d (quux a c))
((e f (mumble b d))
(g (mung a))))
((h (frobnicate c))
((i (glumph h))))
(*print-level* 3))
...)First a, b, and c are bound to the first three values of (zot), and in
parallel, *print-level* is bound to 3; then d and h are bound; then e, f, g, and i are bound.
As this example illustrates, all bindings at a given nesting level are done in
parallel, with all bindings at a deeper level following. Stylistically, it is
expected that init-forms in nested clauses will refer only to variables bound in
containing clause lists. (More on this point below.)
My Misc-Extensions system exports this macro under two names, nlet and let. In my own code, I import it as let, shadowing cl:let. (You'll see it all over the FSet codebase.)
Critical reception: crickets
I published Misc-Extensions at the same time I first published FSet, which I think was 2007 or 2008. I don't recall anyone ever commenting to me either positively or negatively about nlet. My guess is that few if any people besides me have ever used it, but I have no way to know that for sure. In fairness, I didn't make much noise about it; I didn't even add a README with documentation until May 2024, though there was always documentation in the source file.
Let me explain why I like it, though. Consider: why do people ever use let (I mean cl:let) when let* exists? One possible reason is because they want to shadow a variable in the containing scope, but they also need one of the init-forms to refer to the outer variable, and they also need that init-form to be evaluated after the init-form that provides the value for the inner variable. Like this:
If they didn't want to shadow a, they could use let*. (And even if they did want to shadow a, if the two init-forms could be reordered, they could still use let*). Since you never really have to shadow a variable — you can always pick a new name for the inner one — let is redundant; we could always use let*. And yet, in the CL code I've seen (not counting my own), let is several times as common as let*. Why is this?
In the preface to Structure and Interpretation of Computer Programs, Hal Abelson and Gerry Sussman famously said, "Programs must be written for people to read, and only incidentally for machines to execute." While I think that's a tad overstated, it makes an important point.
When let* is used, someone reading the code needs to track the data flow through the clauses, by
seeing which init-forms reference which variables bound in previous
clauses, in order to understand it. In contrast, the use of let communicates immediately that there are no data flow dependences between the clauses. Thus, the reader need not look for them; each of the init-forms can be viewed independently.
The advantage nlet has over let*, then, is that it permits even greater precision in indicating which clauses depend on which other clauses. Let's look again at this example:
(nlet ((a b c (zot))
((d (quux a c))
((e f (mumble b d))
(g (mung a))))
((h (frobnicate c))
((i (glumph h))))
(*print-level* 3))
...)The grouping of the clauses tells the reader at a glance that only the mumble and mung calls can depend on d, and only the glumph call can depend on h. (This isn't enforced, but it's an easy rule to follow when writing.) Any of the calls can depend on *print-level*, but if they actually do, it would have been clearer to put that at the top. If you wanted to make sure that they can't see that binding, you could just wrap the clause in two more parenthesis pairs.
Well. All that said, my guess is that most people are still going to find this syntax a bridge too far. What do you think?
Compromise: mvlet and mvlet*
I have just now released a new Misc-Extensions with two new variations on the above theme, mvlet and mvlet*. These retain the multiple-value binding feature of nlet, but don't support clause nesting; instead they have the familiar semantics of doing fully parallel or fully sequential binding, like let and let* respectively. I think this is probably the right compromise to attract wider use. Do you agree?
It's probably clear by now how to use mvlet and mvlet*, but here's an example anyway:
...
(mvlet ((a b (bar))
(c (baz a)) ; outer 'a'
...)
...)
(mvlet* ((a b (bar))
(c (baz a)) ; inner 'a'
...)
...))
I've looked around for other published macros that provide the same features — a succinct syntax for binding to multiple values, multiple binding clauses, and a choice of parallel or sequential binding — and I haven't found much. Alexandria doesn't have it. I have a faint recollection of seeing a generalized-destructuring macro that allows the use of values expressions as patterns, but I can't seem to find it now. I don't see this functionality in Trivia. The closest thing I can find is Ron Garret's bb macro, but (a) it's in his Ergolib project, which is not in Quicklisp, (b) it does only sequential binding, and (c) it doesn't handle declarations in the body correctly (this is noted as a TODO). If you know of something else, please comment.
I would also note that Dylan, which was created by people who had worked on the design of CL, has a similar syntax for binding to multiple values:
let (a, b, c) = values(...)
I take this as validation of the concept.
I would like this post to start a conversation. I'll post it on Reddit under /r/Common_Lisp; if you use Reddit, that might be the best place. Otherwise, feel free to comment below. Do you use multiple values much? If so, do you agree that the builtin syntax is a bit clunky? Do you think you would use any of the macros I've introduced here?
