Lisp macros are very different to C macros. They are a way to transform lisp code. Macros will be used in Lisp code. During a macroexpansion phase, the Lisp expression will be passed to the macro function. This macro function can do arbitrary computation at macroexpansion time. The result of this call has to be again Lisp code. This Lisp code then is what the interpreter or compiler sees and executes or compiles.
So a typical sequence in a toplevel READ-EVAL-PRINT loop looks like this:
1.) read a Lisp expression. Input comes from a stream and the result is a Lisp expression (interned Lisp data).
(read) -> you type "(incf x)" , Lisp reads a list with two symbols.
2.) macro expand this Lisp expression if it is a macro form. the result is a new Lisp expression (interned Lisp data)
(macroexpand '(incf x)) -> some new Lisp expression
3.) compile the Lisp code
4.) execute the compiled code
5.) print the results
Crucially, the macro language is Lisp itself, so the full power of the language is available. Contrast this with C macros, where a separate language (which doesn't know how C works) is used.
There are few other techniques that can do what Lisp macros do, and although most of the time you don't need them, there are occasions when you really need them, and there isn't much of an alternative.
Trivial example: (defmacro eight () (+ 3 5))If I use this macro in an expression, (eight)it is equivalent to using 8 itself, because the computation is already done at compile time. However, this is easily accomplished by the C preprocessor.
Now consider the similar macro: (defmacro eight () '(+ 3 5))This expression is quoted, so now whenever I invoke (eight)it will return (+ 3 5)which is then evaluated (at run time) to yield 8. This is similar but crucially different from the first example, and this difference could not be achieved using regular functions. Think about this difference in the context of calling rand() rather than using the constant '3'.
Also the macro can return anything it wants, including fragments of programs, so it can be used to build up pieces of programs at compile time - it can generate code. It thus can be used to extend the language. This is where the real power of macros is, and it's also the most difficult part to explain.
Languages that do not support Lisp-style macros in this sense must resort to writing programs that generate programs which are run and whose results are then incorporated into yet another program, etc. I've done this many times in C, and it's a pain.
As a secondary benefit, Lisp macros can be used to do a variety of relatively less important things like add syntactic sugar, but this is trivial compared with their full power.
There are comments here about what you cannot do with them, such as that you cannot use them with apply in Common Lisp because they are not functions. That is an accident of history - Common Lisp handles functions a little strangely in general; in some dialects of Lisp, as long as the macro happens to return a function as a result, you can use the macro with apply, because apply ends up seeing a function.
The fact that you can't use macros with apply in Common Lisp and in most Scheme implementations confuses understanding of the issue, but isn't essential to the ultimate nature of macros. Many, many kinds of macros with a variety of strengths and weaknesses have been proposed and implemented, but if they don't involve doing computation at compile time, then they're not "Lisp macros".
The non-Lisp world (e.g. "macro assemblers", "C macros") usually mean something similar but slightly different with the word "macro": they still mean something that happens at "compile time" or the equivalent, but something that works by string rewriting. Interestingly, unrestricted string rewriting is Turing Complete: you can calculate any computable function by string rewriting. However, C macros, for instance, are crippled in several ways, and other more powerful macro systems like m4 and some assembly macro systems are pretty dangerous to work with precisely because they operate within the domain of strings, rather than on program representations, making Lisp macros a unique combination of power and relative safety and convenience. -- DougMerritt