When you write macros, you're working one meta level up, since you're writing code that generates code (that generates code etc, but one level higher than usual).

From a user perspective it's different. Macros are more limited; not first class and can't be passed around and called like functions.

If we're talking LISP, I believe "if" is a form, not a macro (because it breaks evaluation rules by only evaluating one branch or the other at runtime depending on the evaluation of the conditional).

In fact, MacCarthy invented a multi-branch conditional construct which in M-expressions looked like

  [test1 -> value1; test2 -> value2; T -> default]

The S-expression form was cond:

  (cond (test1 value1) (test2 value2) (T default))

The if macro came later, defined in terms of cond.

Macros are no operationally distinguishable from special operators. You know that a form is a macro because there is a binding for the symbol as a macro, and you can ask for the expansion.

Because macros expand to code that may contain special forms that control evaluation, macros thereby exhibit control over evaluation.

It has to be a macro to allow passing the branches as arguments without both being unconditionally evaluated, otherwise you'd have to use lambdas like Smalltalk or lazy eval a la Haskell.