4.4 Syntax Property Bundles🔗

A syntax property bundle is an immutable tree of syntax properties that has been detached from any particular syntax object tree. Each property in a bundle is addressed by the combination of a syntax path, identifying the subform the property belongs to, and a symbol property key. A bundle contains at most one value for each path and key combination. Property bundles are a plain data representation of metadata that can be attached to and extracted from arbitrary syntax objects and their subforms.

Ordinarily, syntax properties live directly on syntax objects. Representing them separately as plain data lets Resyntax manipulate the properties themselves: bundles can be filtered, merged, inspected, and rearranged without ever touching a syntax object. Resyntax’s expansion analyzers work this way — each analyzer examines a fully expanded module and reports its findings as a syntax property bundle. Resyntax then combines each analyzer’s output bundle together, rearranges the combined bundle, and grafts it onto the original, unexpanded syntax object before analyzing it with refactoring rules.

Although syntax objects themselves permit arbitrary property keys, property keys in a bundle are more limited. A syntax property bundle key must be an interned symbol. This is for two reasons, one specific and one general:

• Interned symbol keys are the only syntax property keys that can be iterated by syntax-property-symbol-keys, so such keys are the only kind that bundles can faithfully transfer between syntax objects. Since the entire purpose of property bundles is to transfer properties between syntax objects, allowing uninterned symbol keys would have no purpose.

• More generally, syntax objects are not plain serializable data. Syntax objects are not safe to transfer from one Racket process to another. This is relied upon by various layers of the Racket macro system and similar low-level systems for encapsulation purposes. Some syntax properties are only used during macro expansion with opaque keys to provide private communication channels between macros that implement some library abstraction. Exposing such keys directly would allow intermediate macros in client code using that library to violate its abstractions. These sorts of opaque keys are often gensyms or similar unserializable unique values, and the Racket macro system takes care to make sure no API exists that provides uncontrolled access to them.