Macros enable developers to extend a language to accomodate future or domain specific needs without waiting for language updates. In this post, we extend the control flow of the language.

Introduction

Much of Lisps longevity is due to its metaprogramming, that is code that treats code as data. Lisp uses the same syntax for both code and data, which makes manipulating code as easy as manipulating data.

Macro functions (or just macros) are just like regular functions, except that the arguments aren’t evaluated before calling, and they should return code (which means data as s-expressions which will be interpreted as code) rather than a value. The macro decides if, when, how and how often an argument is evaluated.

This allows macros to remove repetition, extend the semantics of the programming language, or even create new programming languages within the programming language. Most other languages simply do not have the expressive power to do anything like this, or make it different from built-in constructs or difficult to write.

I’ll demo a couple of simple macros to extend control flow and looping constructs, and I’ll use C# as a contrast to the lisp code.

The intention of this post is meant only to pique your interest in lisp. Production quality implementations of concepts presented here is probably available in libraries for pretty much every lisp out there.

Basic building blocks

Before showing the macros, I’ll explain a few of the building blocks we’ll use.

In lisp, as in many other languages, everything is an expression. If you want to execute some effects, you have to wrap them in an expression which somehow returns a value. The most common construct is progn which accepts many expressions as arguments and returns the result of the last expression. Several other languages do this by default, and lisp also has many forms which does this implicitly.

In C#, you can create a new lexical scope using braces. Variables defined within the scope don’t escape the scope. Many programmers don’t use new scopes outside some statements like functions, if, while etc, but they are still available if you want to control visibility of variables, disposing, finalizing etc.

A new scope can be created using let in lisp. While progn allows several expressions and returns the last, let also allows creating new variables in this scope. let has an implicit progn so you can pass several expressions instead of explicitly stating a progn.

The fact that everything is an expression means we don’t have to declare variables ahead of initialization with dummy values.


In lisp, as in other languages with expressions rather than statements, we can write the following.

Code as data and code that writes code

That’s about the basics we need before looking into how macros work. Syntax in programming language is parsed into an abstract syntax tree (AST) in order to be further analyzed and manipulated. In lisp we write our programs directly in an AST.

So how can we represent the following code as data?

list creates a list, quote returns the exact symbol/value without evaluating it.

Fortunately, we don’t have to write code as above. By quoting the first list, everything within is quoted. We can thus rewrite the above with just a single quote at the start, getting the exact same code, but this time as data!

When creating code that manipulates code, it’s often useful to evaluate certain expressions. When we use the verbose syntax, this is easy. (list (quote +) x 1) will evaluate x as it’s not quoted, but not +.

Let’s say we have the following code, and we want to return the code (+ 1 2). Our first attempt returns (+ x 2), which isn’t what we want.

We have a form similar to quote called quasiquote or `. When using this form, we can unquote the expression using ,, which will evaluate the expression.

There is also unquote-splicing, ,@, which will unquote a list and flatten it (remove the “(list” and “)” part), e.g. `(1 ,@(list 2 3) 4) equals '(1 2 3 4).

With the basics out of the way, let’s start extending the language with some new control flows.

New control flow abstractions

A regular C# if statement looks pretty much the same as a lisp if expression.

But often, we only care about the “then” or “else” clause.


The “else” clause is often written by negating test rather than using an empty “then” block


Let’s create two new control flow constructs, when for the “then” clause and unless for the “else” clause. This removes some repetition as well as making the intent clearer.

Rather than


We’ll write

It makes it very clear that there is no “else” clause, and we can use an implicit block. Notice that the definition looks pretty much exactly as we would have written the if expression simply because code and data has the same syntax.


We’ll do the same for the “else” case.

We could have defined unless in terms of when and negating test, but let’s use if directly to avoid the extra function call.

As a side-note, truthy and falsy is quite different in some Lisps like Common Lisp (CL) which this article is using. In CL, only nil is falsy and every other value is truthy. This means functions can return actual data instead of true / false, and we don’t have to inspect the value or revert to using only booleans.

The pattern below is quite common, but in Lisp we don’t need to store the temporary or checking against a particular value.

But what if the block needs the value too? In that case we need to store the value in a variable in order to use it later.

We can write this using a let

or is using this fact to return a value rather than evaluating to a boolean. The following is quite common code, and is easily expressed just using or.

Binding the test only for the success case

The pattern of binding something and then using it within an expression is a common pattern. In other languages we annoyingly often create temporary values which outlive the expression they are used in. But using macros, we can do this The Right Way; we’ll create if-let, when-let and unless-let. Using these, our code just becomes

The macros are no more difficult than what we’ve already seen.

Anaphoric macros

But we’re not finished yet. We don’t really care about the name something in the expression. We could call it it and make it available in the scope. This is called “anaphoric” macros. Our previous example thus becomes

Let’s see how a lisp expression using awhen and or would look like in C#.

Creating new loops

Let’s turn our head over to loops which also has some common patterns; looping until some condition is met. The loop in C# will look different based on what kind of thing we expect. Here is a simple boolean to become true, and other types of checks would look different.

But any complex expression is possible

Looping forever is normal in background processes. It’s easy to express in most languages, but being more explicit could improve readability.

Conclusion

The examples are quite contrived and don’t show the real power of macros. But hopefully they show that macros are within reach and allow you to extend your language to fit your domain. Building a program bottom-up by creating a language that allows you to express a solution to your problem clearly, is one of the great features of lisp.

lisp

A quick peek at lisp macros