Chapter 10

Macros

Patterns

Approximately speaking, a pattern looks like the construct that it matches, but contains pattern variables that bind to portions of the construct. Hence, a left-hand side in the main-rule-set looks like a macro call. However, the grammar of patterns is not the same as the grammar of programs, but contains just what is required to match the portions of the Dylan grammar that are extensible by macros. Patterns have a simple nested grammar, with semicolons, commas, and brackets used to indicate levels of nesting. See the definition of pattern in Appendix A, BNF.

A pattern matches a fragment (a sequence of elementary fragments) by executing the following algorithm from left to right. It is easy to create patterns that are ambiguous when considered as grammars. This ambiguity is resolved by the left to right processing order and the specified try-shortest-first order for matching wildcards. Pattern matching succeeds only if all sub-patterns match. If pattern matching fails, the current rule fails and control passes to the next rule in the current rule set. If all patterns in a rule set fail to match, the macro call is invalid.

Multiple occurrences of the same pattern variable name in a single rule's left-hand side are not valid.

A pattern matches a fragment as follows:

A pattern-list matches a fragment as follows:

A pattern-sequence matches a fragment as follows:

A simple-pattern matches a fragment as follows:

A binding-pattern matches a fragment as follows:

A pattern-variable matches a fragment as follows:

A property-list-pattern matches a fragment as follows:

Special Rules for Definitions

A list-style definition parses as the core reserved word define, an optional sequence of modifiers, a define-list-word, and a possibly-empty list-fragment. The left-hand side of a list-style-definition-rule matches this by treating the definition-head as a pattern-sequence and matching it to the sequence of modifiers, and then matching the pattern to the list-fragment. If no definition-head is present, the sequence of modifiers must be empty. If no pattern is present, the list-fragment must be empty. The word define and the define-list-word do not participate in the pattern match because they were already used to identify the macro being called and because the spelling of the define-list-word might have been changed by renaming the macro during module importing.

A body-style definition parses as the core reserved word define, an optional sequence of modifiers, a define-body-word, a possibly-empty body-fragment, the core reserved word end, and optional repetitions of the define-body-word and the name (if any) that is the first token of the body-fragment. The left-hand side of a body-style-definition-rule matches this by treating the definition-head as a pattern-sequence and matching it to the sequence of modifiers, and then matching the pattern to the body-fragment. If no definition-head is present, the sequence of modifiers must be empty. If no pattern is present, the body-fragment must be empty. If the body-fragment ends in a semicolon, this semicolon is removed before matching. The optional semicolon in the rule is just decoration and does not participate in the pattern match. The word define and the define-body-word do not participate in the pattern match because they were already used to identify the macro being called and because the spelling of the define-body-word might have been changed by renaming the macro during module importing. The word end and the two optional items following it in the macro call are checked during parsing, and so do not participate in the pattern match.

It is an error for a definition-head to contain more than one wildcard.

Special Rules for Statements

A statement parses as a begin-word, a possibly-empty body-fragment, the core reserved word end, and an optional repetition of the begin-word. The left-hand side of a statement-rule matches this by matching the pattern to the body-fragment. If the rule does not contain a pattern, the body-fragment must be empty. If the body-fragment ends in a semicolon, this semicolon is removed before matching. The optional semicolon in the rule is just decoration and does not participate in the pattern match. The begin-word does not participate in the pattern match because it was already used to identify the macro being called and because its spelling might have been changed by renaming the macro during module importing. The word end and the optional item following it in the macro call are checked during parsing, and so do not participate in the pattern match.

Special Rules for Function Macros

A call to a function macro parses as a function-word followed by a parenthesized, possibly-empty body-fragment. The left-hand side of a function-rule matches this by matching the pattern to the body-fragment. If the rule does not contain a pattern, the body-fragment must be empty. The function-word does not participate in the pattern match because it was already used to identify the macro being called and because its spelling might have been changed by renaming the macro during module importing. The parentheses in the rule are just decoration and do not participate in the pattern match.

A function macro can also be invoked by any of the shorthand syntax constructs available for invoking functions. In this case, the arguments are always parsed expression fragments, as described on page 146. However, the left-hand side of a function-rule has to use function-macro-call syntax even if the macro is intended to be called by operator, slot reference, or element reference syntax.