8.4 Specifying syntax with syntax classes
Syntax classes provide an abstraction mechanism for syntax patterns. Built-in syntax classes are supplied that recognize basic classes such as identifier and keyword. Programmers can compose basic syntax classes to build specifications of more complex syntax, such as lists of distinct identifiers and formal arguments with keywords. Macros that manipulate the same syntactic structures can share syntax class definitions.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
A syntax class may have formal parameters, in which case they are bound as variables in the body. Syntax classes support optional arguments and keyword arguments using the same syntax as lambda. The body of the syntax-class definition contains a non-empty sequence of pattern variants.
The following options are supported:
#:attributes (attr-arity-decl ...)
attr-arity-decl = attr-id | (attr-id depth) Declares the attributes of the syntax class. An attribute arity declaration consists of the attribute name and optionally its ellipsis depth (zero if not explicitly specified).
If the attributes are not explicitly listed, they are inferred as the set of all pattern variables occurring in every variant of the syntax class. Pattern variables that occur at different ellipsis depths are not included, nor are nested attributes from annotated pattern variables.
#:description description-expr
description-expr : (or/c string? #f) The description argument is evaluated in a scope containing the syntax class’s parameters. If the result is a string, it is used in error messages involving the syntax class. For example, if a term is rejected by the syntax class, an error of the form "expected description" may be synthesized. If the result is #f, the syntax class is skipped in the search for a description to report.
If the option is not given absent, the name of the syntax class is used instead.
#:opaque Indicates that errors should not be reported with respect to the internal structure of the syntax class.
#:commit Directs the syntax class to “commit” to the first successful match. When a variant succeeds, all choice points within the syntax class are discarded. See also ~commit.
#:no-delimit-cut By default, a cut (~!) within a syntax class only discards choice points within the syntax class. That is, the body of the syntax class acts as though it is wrapped in a ~delimit-cut form. If #:no-delimit-cut is specified, a cut may affect choice points of the syntax class’s calling context (another syntax class’s patterns or a syntax-parse form).
It is an error to use both #:commit and #:no-delimit-cut.
#:literals (literal-entry)
#:literal-sets (literal-set ...)
#:conventions (convention-id ...) Declares the literals and conventions that apply to the syntax class’s variant patterns and their immediate #:with clauses. Patterns occuring within subexpressions of the syntax class (for example, on the right-hand side of a #:fail-when clause) are not affected.
These options have the same meaning as in syntax-parse.
Each variant of a syntax class is specified as a separate pattern-form whose syntax pattern is a single-term pattern.
| ||
|
The options are the same as for define-syntax-class.
Each variant of a splicing syntax class is specified as a separate pattern-form whose syntax pattern is a head pattern.
(pattern syntax-pattern pattern-directive ...) |
When used within define-syntax-class, syntax-pattern should be a single-term pattern; within define-splicing-syntax-class, it should be a head pattern.
The attributes of the variant are the attributes of the pattern together with all attributes bound by #:with clauses, including nested attributes produced by syntax classes associated with the pattern variables.
8.4.1 Pattern directives
Both the parsing forms and syntax class definition forms support pattern directives for annotating syntax patterns and specifying side conditions. The grammar for pattern directives follows:
pattern-directive | = | #:declare pattern-id syntax-class-id | ||
| | #:declare pattern-id (syntax-class-id arg ...) | |||
| | #:with syntax-pattern expr | |||
| | #:attr attr-arity-decl expr | |||
| | #:fail-when condition-expr message-expr | |||
| | #:fail-unless condition-expr message-expr | |||
| | #:when condition-expr | |||
| | #:do [def-or-expr ...] |
#:declare pvar-id syntax-class-id
#:declare pvar-id (syntax-class-id arg ...) The first form is equivalent to using the pvar-id:syntax-class-id form in the pattern (but it is illegal to use both for the same pattern variable).
The second form allows the use of parameterized syntax classes, which cannot be expressed using the “colon” notation. The args are evaluated outside the scope of any of the attribute bindings from pattern that the #:declare directive applies to. Keyword arguments are supported, using the same syntax as in #%app.
#:with syntax-pattern stx-expr Evaluates the stx-expr in the context of all previous attribute bindings and matches it against the pattern. If the match succeeds, the pattern’s attributes are added to environment for the evaluation of subsequent side conditions. If the #:with match fails, the matching process backtracks. Since a syntax object may match a pattern in several ways, backtracking may cause the same clause to be tried multiple times before the next clause is reached.
#:attr attr-arity-decl expr Evaluates the expr in the context of all previous attribute bindings and binds it to the given attribute. The value of expr need not be syntax.
#:fail-when condition-expr message-expr
message-expr : (or/c string? #f) Evaluates the condition-expr in the context of all previous attribute bindings. If the value is any true value (not #f), the matching process backtracks (with the given message); otherwise, it continues. If the value of the condition expression is a syntax object, it is indicated as the cause of the error.
If the message-expr produces a string it is used as the failure message; otherwise the failure is reported in terms of the enclosing descriptions.
#:fail-unless condition-expr message-expr
message-expr : (or/c string? #f) Like #:fail-when with the condition negated.
#:when condition-expr Evaluates the condition-expr in the context of all previous attribute bindings. If the value is #f, the matching process backtracks. In other words, #:when is like #:fail-unless without the message argument.
#:do [def-or-expr ...] Takes a sequence of definitions and expressions, which may be intermixed, and evaluates them in the scope of all previous attribute bindings. The names bound by the definitions are in scope in the expressions of subsequent patterns and clauses.
There is currently no way to bind attributes using a #:do block. It is an error to shadow an attribute binding with a definition in a #:do block.
8.4.2 Pattern variables and attributes
An attribute is a name bound by a syntax pattern. An attribute can be a pattern variable itself, or it can be a nested attribute bound by an annotated pattern variable. The name of a nested attribute is computed by concatenating the pattern variable name with the syntax class’s exported attribute’s name, separated by a dot (see the example below).
Attribute names cannot be used directly as expressions; that is, attributes are not variables. Instead, an attribute’s value can be gotten using the attribute special form.
(attribute attr-id) |
The value of an attribute need not be syntax. Non-syntax-valued attributes can be used to return a parsed representation of a subterm or the results of an analysis on the subterm. A non-syntax-valued attribute should be bound using the #:attr directive or a ~bind pattern.
Examples: | ||||||
| ||||||
| ||||||
'#hash((b . 2) (c . 3) (a . 1)) |
A syntax-valued attribute is an attribute whose value is a syntax object or a syntax list of the appropriate ellipsis depth. Syntax-valued attributes can be used within syntax, quasisyntax, etc as part of a syntax template. If a non-syntax-valued attribute is used in a syntax template, a runtime error is signalled.
Examples: | |||
| |||
#<syntax:98:0 (a b c)> | |||
| |||
t.hash: attribute is bound to non-syntax value: '#hash((b . | |||
2) (c . 3) (a . 1)) at: t.hash |
Every attribute has an associated ellipsis depth that determines how it can be used in a syntax template (see the discussion of ellipses in syntax). For a pattern variable, the ellipsis depth is the number of ellipses the pattern variable “occurs under” in the pattern. For a nested attribute the depth is the sum of the pattern variable’s depth and the depth of the attribute in the syntax class. Consider the following code:
(define-syntax-class quark |
(pattern (a b ...))) |
(syntax-parse some-term |
[(x (y:quark ...) ... z:quark) |
some-code]) |
The syntax class quark exports two attributes: a at depth 0 and b at depth 1. The syntax-parse pattern has three pattern variables: x at depth 0, y at depth 2, and z at depth 0. Since x and y are annotated with the quark syntax class, the pattern also binds the following nested attributes: y.a at depth 2, y.b at depth 3, z.a at depth 0, and z.b at depth 1.
An attribute’s ellipsis nesting depth is not a guarantee that its value has that level of list nesting. In particular, ~or and ~optional patterns may result in attributes with fewer than expected levels of list nesting.
Example: | |||
| |||
#f |