I’ve gotten both some comments and some e-mail from people in response to my mini-rant about Erlang’s macros. I started replying in comments, but it got long enough that I thought it made sense to promote it up to a top-level post. It’s not really an Erlang issue, but a general language issue, and my opinions concerning it end up getting into some programming language design and philosophy issues. If, like me, you think that things like that are fun, then read on!<\/p>\n
<\/p>\n
I’ll start at the absolute beginning. What’s a macro?<\/p>\n
A macro is a meta-structure in a language which defines a translation of the code to be performed before compiling or running that code. To give a simple example, let’s look at a simple C++ program:<\/p>\n
\n#include <iostream.h>\n#define f(x) (2*x)\nint main() {\ncout << f(3) << endl;\n}\n<\/pre>\n “f<\/code>” is a simple macro. Whenever you write “f(x)<\/code>” in a program, the
\npre-processor, which runs before<\/em> the compiler, will replace it with “(2*x)<\/code>“. So in the main function, the macro preprocessor replaces “f(3)<\/code>” so that the program that gets compiled is actually the following:<\/p>\n\n#include <iostream.h>\nint main() {\ncout << (2*3) << endl;\n}\n<\/pre>\n Whatever you put inside of “f(...)<\/code>” will be put into the replacement. In the case of C, the macros are textual<\/em>: the compiler makes no attempt to verify that the body of the macro is in any way valid C++ code. It just does a purely textual substitution. This means that it’s possible to write a macro that generates something totally invalid and incomprehensible. If you invoke the above macro with “f(+)<\/code>“, the preprocessor will expand it to “(2*+)<\/code>“.<\/p>\n Textual replacement macros are the trickiest and most error prone. More sophisticated macro systems, like the ones in Lisp, work on some form of parse tree. Lisp code can be represented in terms of the basic list types of lisp, and the macro system takes advantage of that to describe how to construct code in a macro by performing list manipulations. For example, in CommonLisp I could use the following to define a simple “while” loop in terms of the built-in “do” loop:<\/p>\n
\n(defmacro while (test &rest body)\n(append (list 'do nil (list (list 'not test)))\nbody))\n<\/pre>\n What this says is: when you see an expression that looks like a function call to the function “test”, assign the first parameter to the parameter “test”; assign a list containing the rest of the parameters to a variable named “body”, and then execute the macro code using those parameter bindings,
\ngenerating as a result the list form of a lisp syntax tree. So, for example, if you wrote “(while (< x 10) (setq x (+ x 1)))<\/code>“, the macro would evaluate the expression “(append (list 'do nil (list (list 'not (< x 10)))) (setq x (+ x 1)))<\/code>“, which would evaluate to “(do () ((not (< x 10))) (setq x (+ x 1)))<\/code>“, which is a valid Lisp loop.<\/p>\n The Lisp macro system is amazingly powerful: you’ve got a full Turing-complete meta-programming system available to you for extending the syntax of Lisp, and it’s been used for building a huge variety of amazing things. There’s an object-oriented programming system implemented in Lisp called CLOS whose original implementation used no<\/em> compiler changes at all – just a lot of skeleton code, with definitions glued together using macros.<\/p>\n So why do I dislike macros so much? I don’t, in theory. The problem is what happens in practice – most programming language macro systems – including the two example ones I described above, stink. What I dislike is how they’re generally built. You can fix most<\/em> (but not all) of the problems caused by macros if you’ve got a good enough macro system. But because most macro systems rely on a simple expansion-and-substitution, they’re prone to creating all sort of problems. I’ll walk you through a few examples, to give you a sense of what I mean.<\/p>\n The most obvious example of what’s wrong with substitution macros is that they can create all sorts of unfortunate interactions with the evaluation semantics of the system. Macro evaluations don’t work
\nthe same as function evaluations, even though they usually look the same. The unfortunate effect of
\nthis is that you can get very unexpected semantic results from using them. Here’s a typical example. Suppose I want a macro that doubles its parameter, regardless of type. Any type that supports
\nthe “+” operator should be usable for the macro. So if I give it a “3”, it should return “3+3” (which will evaluated by constant propagation to “6”); if you give it an “A”, it should return “A”+”A” (which evaluates to “AA”.) I can do that in C++ with:<\/p>\n
\n#define double(x) (x+x)\n<\/pre>\n Now, suppose I use that in a program:<\/p>\n
\n#include <iostream.h>\n#define double(x) (x+x)\nint main() {\nfor (int i=0; i < 10; i++) {\ncout << \"doubling \" << i << \" gives \" << double(i) << endl;\n}\n}\n<\/pre>\nThat generates the output:<\/p>\n
\ndoubling 0 gives 0\ndoubling 1 gives 2\ndoubling 2 gives 4\ndoubling 3 gives 6\ndoubling 4 gives 8\ndoubling 5 gives 10\ndoubling 6 gives 12\ndoubling 7 gives 14\ndoubling 8 gives 16\ndoubling 9 gives 18\n<\/pre>\n So far, so good. Now suppose I get rid of the for loop, and write it in a C++-ish fashion
\nusing a while loop and the auto-increment operator:<\/p>\n
\n#include <iostream.h>\n#define double(x) (x+x)\nint main() {\nint i = 0;\nwhile (i < 10) {\ncout << \"doubling \" << i << \" gives \" << double(i++) << endl;\n}\n}\n<\/pre>\n If “double” were a function, this would generate the same result as the original
\nprogram. But since “double” is a macro, if we run it, we get:<\/p>\n
\ndoubling 2 gives 0\ndoubling 4 gives 4\ndoubling 6 gives 8\ndoubling 8 gives 12\ndoubling 10 gives 16\n<\/pre>\n We get a very odd, unexpected result. That’s because the expansion of “double<\/code>” turns “i++<\/code>” into
\n“(i++ + i++)<\/code>“, incrementing “i<\/code>” twice each iteration. That’s very typical of C-style macros: you can get very unexpected results from macros, because they can end up executing parameters either more than once, or not at all, so parameters with any kind of state-effects can cause all sorts of trouble. To make matters worse, the invisibility of macros means that unless you’ve seen the implementation of a library,
\nyou don’t know<\/em> which calls are function calls and which are macro invocations, so you need to check implementations to figure out what kind of parameters you can use.<\/p>\n You can make the argument that that’s sloppy programming: that passing a parameter expression that has a side effect is just bad, and shouldn’t be done. That’s not an unreasonable argument, except for the fact that you don’t always know<\/em> when a parameter expression causes a side effect. I’ve been bitten more than once by things that are described as pure, idempotent functions, but which generate error messages – and having them generate the same message multiple times because of an unfortunate macro effect.<\/p>\n But even if you ban side-effecting parameters to all calls, effectively eliminating the
\nissue above, there’s still one major potential source of grief in most macro systems. It’s a bit more
\nsubtle, and more serious because of its subtlety. You can use a macro for years with no ill effects, and then get screwed by this. It’s called name capture<\/em>. A trivial example of it could happen with the example above: “double” is the name of a built-in type in C++, and “double” written as a function
\nis supposed to be a type conversion. But because we’ve implemented it as a macro, the type conversions aren’t going to do what you expect: they’ve been replaced, because the macro system captured the name.<\/p>\n For a more interesting and subtle example of this, we can shift back to Lisp, suppose you used
\nmacros to implement a simple for loop. And suppose that you did it in a way that introduced a variable
\nin your macro, like the following:<\/p>\n
\n(defmacro for (var init incr bound &rest body)\n`(let ((,var ,init))\n(while (< ,bound ,var)\n,@body\n(setq old-val ,var)\n(setq var (+ old-val ,incr)))))\n<\/pre>\n In here, “old-val<\/code>” is used as a counter to hold the previous value of the iteration. It’s not really
\nneeded here, but it allows me to illustrate the problem without getting into an overly complicated
\nexample. What happens if you use the “for<\/code>” macro in a function which already has a variable named
\n“old-var<\/code>“? What happens is a disaster: the macro “captures” the existing variable, and changes its
\nvalue. The variable that’s used in the macro-expansion is in the same namespace as variables in the
\ncontext where the macro is used, and so it can overlap or collide with existing variables. You’ll never
\nknow that this is possible until your program starts mysteriously getting wrong results, because you
\nfinally used the macro in a context where a name was already defined. To get around this, Lisp has a
\nbunch of functions that generate new symbols that are guaranteed never to have been seen before, but
\nwriting code that’s completely safe, so that it never accidentally captures or shadows an existing
\nvariable is a very tricky skill.<\/p>\n There are ways around the syntactic capture issue, but they’re very rare. In fact, I really only know of one – the hygenic macro system in Scheme. (I’ve seen pretty much exactly the same thing crop up in some other Lisp variants, like Dylan, and even one prolog variant.) What these systems do is provide a sort of pattern matching facility that lets you grab parts of the expression and re-arrange them. But variables used in the macro are bound at the point where the macro is declared<\/em>, not at the point where the macro is used. There’s usually a way to capture something if you specifically want to.<\/p>\n