(require mzlib/defmacro)

In the first form, expr must produce a procedure. In the second form, formals determines the formal arguments of the procedure, as in lambda, and the exprs are the procedure body. The last form, with defmacro, is like the second form, but with slightly different parentheses.

In all cases, the procedure is generated in the transformer environment, not the normal environment.

In a use of the macro,

  (id datum ...)

syntax->datum is applied to the expression, and the transformer procedure is applied to the cdr of the resulting list. If the number of datums does not match the procedure’s arity, or if id is used in a context that does not match the above pattern, then a syntax error is reported.

After the macro procedure returns, the result is compared to the procedure’s arguments. For each value that appears exactly once within the arguments (or, more precisely, within the S-expression derived from the original source syntax), if the same value appears in the result, it is replaced with a syntax object from the original expression. This heuristic substitution preserves source location information in many cases, despite the macro procedure’s operation on raw S-expressions.

After substituting syntax objects for preserved values, the entire macro result is converted to syntax with datum->syntax. The original expression supplies the lexical context and source location for converted elements.

Important: Although define-macro is non-hygienic, it is still restricted by PLT Scheme’s phase separation rules. This means that a macro cannot access run-time bindings, because it is executed in the syntax-expansion phase. Translating code that involves define-macro or defmacro from an implementation without this restriction usually implies separating macro related functionality into a begin-for-syntax or a module (that will be imported with require-for-syntax) and properly distinguishing syntactic information from run-time information.