In computer science, hygienic macros are macros whose expansion is guaranteed not to cause the accidental capture of identifiers. They are a feature of programming languages such as Scheme, Dylan, Rust, Nim, and Julia. The general problem of accidental capture was well known in the Lisp community before the introduction of hygienic macros. Macro writers would use language features that would generate unique identifiers (e.g., gensym) or use obfuscated identifiers to avoid the problem. Hygienic macros are a programmatic solution to the capture problem that is integrated into the macro expander. The term "hygiene" was coined in Kohlbecker et al.'s 1986 paper that introduced hygienic macro expansion, inspired by terminology used in mathematics.
The hygiene problem
Variable shadowing In programming languages that have non-hygienic macro systems, it is possible for existing variable bindings to be hidden from a macro by variable bindings that are created during its expansion. In C, this problem can be illustrated by the following fragment:
Running the above through the C preprocessor produces:
The variable a declared in the top scope is shadowed by the a variable in the macro, which introduces a new scope. As a result, a is never altered by the execution of the program, as the output of the compiled program shows:
a is now 4, b is now 9
Standard library function redefinition The hygiene problem can extend beyond variable bindings. Consider this Common Lisp macro:
While there are no references to variables in this macro, it assumes the symbols "if", "not", and "progn" are all bound to their usual definitions in the standard library. If, however the above macro is used in the following code:
The definition of "not" has been locally altered and so the expansion of my-unless changes. Note however that for Common Lisp this behavior is forbidden, as per 11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs. It is also possible to completely redefine functions anyway. Some implementations of Common Lisp provide Package Locks to prevent the user to change definitions in packages by mistake.
Program-defined function redefinition Of course, the problem can occur for program-defined functions in a similar way:
The use site redefines user-defined-operator and hence changes the behavior of the macro.
Strategies used in languages that lack hygienic macros The hygiene problem can be resolved with conventional macros using several alternative solutions.
Obfuscation The simplest solution, if temporary storage is needed during macro expansion, is to use unusual variables names in the macro in hope that the same names will never be used by the rest of the program.
Until a variable named INCIa is created, this solution produces the correct output:
a is now 5, b is now 9
The problem is solved for the current program, but this solution is not robust. The variables used inside the macro and those in the rest of the program have to be kept in sync by the programmer. Specifically, using the macro INCI on a variable INCIa is going to fail in the same way that the original macro failed on a variable a.
Temporary symbol creation In some programming languages, it is possible for a new variable name, or symbol, to be generated and bound to a temporary location. The language processing system ensures that this never clashes with another name or location in the execution environment. The responsibility for choosing to use this feature within the body of a macro definition is left to the programmer. This method was used in MacLisp, where a function named gensym could be used to generate a new symbol name. Similar functions (usually named gensym as well) exist in many Lisp-like languages, including the widely implemented Common Lisp standard and Elisp. Although symbol creation solves the variable shadowing issue, it does not directly solve the issue of function redefinition. However, gensym, macro facilities, and standard library functions are sufficient to embed hygienic macros in an unhygienic language.
Read-time uninterned symbol This is similar to obfuscation in that a single name is shared by multiple expansions of the same macro. Unlike an unusual name, however, a read time uninterned symbol is used (denoted by the #: notation), for which it is impossible to occur outside of the macro, similar to gensym.
Packages Using packages such as in Common Lisp, the macro simply uses a private symbol from the package in which the macro is defined. The symbol will not accidentally occur in user code. User code would have to reach inside the package using the double colon (::) notation to give itself permission to use the private symbol, for instance cool-macros::secret-sym. At that point, the issue of accidental lack of hygiene is moot. Furthermore the ANSI Common Lisp standard categorizes redefining standard functions and operators, globally or locally, as invoking undefined behavior. Such usage can be thus diagnosed by the implementation as erroneous. Thus the Lisp package system provide a viable, complete solution to the macro hygiene problem, which can be regarded as an instance of name clashing. For example, in the program-defined function redefinition example, the my-unless macro can reside in its own package, where user-defined-operator is a private symbol in that package. The symbol user-defined-operator occurring in the user code will then be a different symbol, unrelated to the one used in the definition of the my-unless macro.
Literal objects In some languages the expansion of a macro does not need to correspond to textual code; rather than expanding to an expression containing the symbol f, a macro may produce an expansion containing the actual object referred to by f. Similarly if the macro needs to use local variables or objects defined in the macro's package, it can expand to an invocation of a closure object whose enclosing lexical environment is that of the macro definition.
… excerpt ends here. Continue reading the full article.
