3.4 Inspecting Expanded Code
Synopsis: How to analyze and transform expressions and definitions.
Examples: class, public, and define/public
If you don’t know how to put it back together, don’t take it apart.
You don’t know how to put it back together.
The reason is simply that macros give expressions an unknown and variable structure. What appears to be a procedure application might be a macro use. What appears to be a variable reference might be an identifier macro. What appears to be a set! expression might invoke a set!-transformer. A macro that checks for quoted constants will miss quasiquote expressions that turn out to be constant. It is safer to avoid inspecting expressions entirely.
The sole exception, the case where it is permissible to analyze and transform expressions or definitions, is when the terms are already expanded to core syntactic forms. In that case, the structure of the expression is known, because macros have been eliminated.
There are two main varieties of expanded syntax: head-expanded and fully-expanded.
Head-expanded syntax has been expanded until the outermost syntactic form is a primitive syntactic form (or possibly a special subform whose keyword was in the stop list argument to local-expand). The inner forms may still be unexpanded. For examples of dealing with head-expanded code, see Subforms with Internal Definition Contexts. It is generally safe to head-expand to uncover definitions and then analyze the definition structure. It is generally not safe to analyze and transform expressions without worrying about certificates.
Fully-expanded syntax contains no macro uses at all. It may or may not contain macro definitions, depending on the arguments given to local-expand.