1.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, 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.

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.

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.

1.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:

#:declare pvar-id stxclass maybe-role

stxclass   =   syntax-class-id     |   (syntax-class-id arg ...)           maybe-role   =       |   #:role role-expr

Associates pvar-id with a syntax class and possibly a role, equivalent to replacing each occurrence of pvar-id in the pattern with (~var pvar-id stxclass maybe-role). The second form of stxclass allows the use of parameterized syntax classes, which cannot be expressed using the “colon” notation. The args are evaluated in the scope where the pvar-id occurs in the pattern. 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.

1.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.

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.

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 signaled.

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.