The Fortress Language Specification - CiteSeerX

Because syntax expanders are defined at the top level of program components, and because they are syntactically
distinguished, they can be identified before scanning or parsing (but after ASCII conversion). Use sites are then
identified and expanded before parsing occurs.
Syntax expansion takes a sequence of Unicode characters and yields a sequence of Unicode characters and syntax
trees, where all the syntax expanders have been replaced by syntax trees. This result has type SourceAssembly.
Syntax expansion proceeds from left to right as follows. First, the source is scanned for opening delimiters of syntax
expanders, stopping at the leftmost one. We call this scanning Fortress-source scanning.
If the opening delimiter of a syntax expander is encountered during Fortress-source scanning, the source is scanned
rightward until the first occurrence of either an opening delimiter of some syntax expander (possibly another use of the
same expander), or the terminating delimiter of that syntax expander, is found. (If no matching terminating delimiter
is found in the remainder of the program, it is a static error.) We call this scanning expander scanning.
If an opening delimiter is encountered before the terminating delimiter, there is a nested use site of another syntax
expander. The nested use site is processed, and then expander scanning continues rightward of that use site. Thus, the
processing of syntax expanders is recursive, syntax expanders may be nested arbitrarily, and expanders are processed
from the leftmost-innermost occurrence outward and rightward.
When the terminating delimiter is encountered during expander scanning, the scanning is terminated, the resulting
SourceAssembly is bound to the contents parameter of the expander, and then the body of the expander is evaluated.
The result of evaluating this body has type SyntaxTree, and it is placed into the resulting SourceAssembly in place
of the expander in the scanned source.
36.4.1 Introduced Variable Names
Often, when expanding concrete syntax for a domain-specific language, it is useful to introduce variable binding
constructs into the resulting SyntaxTree. It is required that such bindings, in general, respect the rules of hygiene
and referential transparency [7]. Several aspects of the Fortress semantics allow the library programmer to ensure
referential transparency of syntax expanders:
1. A component exporting an API A that includes a syntax expander must not import APIs that are not also
imported by A.
2. Syntax expanders must expand to SyntaxTrees of expressions.
3. Shadowing of identifiers is not allowed.
Thus, syntax expanders cannot expand into new top-level identifiers. Moreover, provided that the library programmer
is careful to ensure that all top-level identifier references appearing in expanded code are fully qualified identifiers
exported by APIs, all top-level identifiers referred to in the definition of a syntax expander are visible at all use sites.
To ensure hygiene, all variables bound in a SyntaxTree resulting from an expansion are renamed, following the
syntax-case system of Dybvig et al. [9].
36.4.2 Comments and Syntax Expansion
Comments are not recognized before syntax expansion (the embedded syntax may have its own commenting syntax):
during expander scanning, an opening or terminating delimiter that occurs in what appears to be a Fortress comment
is nonetheless recognized as an opening or terminating delimiter for that expander. Comments can be viewed as uses
of a syntax expander, with special opening and terminating delimiters.
243