Macros and Metaprogramming

Macros are one reason Clojure feels like a language toolkit rather than only a library ecosystem. A macro receives code as data, transforms it, and returns new code for evaluation.

That sounds exotic, but you use macros early:

The practical lesson is not “macros are magic.” It is “some abstractions need to control code shape or evaluation.”

Macro vs Function

If a function can express the idea clearly, use a function. Functions are easier to test, compose, debug, and explain.

A Small Macro Example

1(defmacro unless [test & body]
2  `(if (not ~test)
3     (do ~@body)))

Macro expansion shows what code is produced:

1(macroexpand-1 '(unless ready? (println "not ready")))
2;; => (if (clojure.core/not ready?) (do (println "not ready")))

macroexpand-1 is a key debugging tool. It lets you inspect the generated form before normal evaluation.

Why Functions Stay The Default

Most business code should not be macro code. Prefer functions when you want to:

• transform maps, vectors, sets, or sequences
• parameterize behavior
• hide ordinary implementation details
• reuse runtime logic
• write direct tests over inputs and outputs

Reach for a macro only when the problem is really about code shape or evaluation order.

A Java Mental Model

Macros are closer to compile-time abstract syntax tree transformation than to reflection. They are not runtime hooks that inspect objects. They rewrite forms before those forms are evaluated.

That power has a maintenance cost:

Use macros as a precision tool, not as a style badge.

Decision Rule

Ask in order:

1. Can this be a plain function?
2. Can it be data plus a plain function?
3. Do I need to prevent, delay, repeat, or reshape evaluation?
4. Will the macro make call sites clearer after the expansion is understood?

If the answer to the first or second question is yes, stop there.

Quiz: Macros