► |  | Syntax: Meta-Programming Helpers

1 | Parsing and Specifying Syntax
2 | Syntax Object Helpers
3 | Datum Pattern Matching
4 | Module-Processing Helpers
5 | Macro Transformer Helpers
6 | Reader Helpers
7 | Source Locations
8 | Preserving Source Locations
9 | Non-Module Compilation And Expansion
10 | Trusting Standard Recertifying Transformers
11 | Attaching Documentation to Exports
| Index

▼ | 1 | Parsing and Specifying Syntax

1.1 | Introduction
1.2 | Examples
1.3 | Parsing Syntax
1.4 | Specifying Syntax with Syntax Classes
1.5 | Syntax Patterns
1.6 | Defining Simple Macros
1.7 | Literal Sets and Conventions
1.8 | Library Syntax Classes and Literal Sets
1.9 | Debugging and Inspection Tools
1.10 | Experimental

► | 1.4 | Specifying Syntax with Syntax Classes

1.4.1 | Pattern Directives
1.4.2 | Pattern Variables and Attributes

On this page:

define-syntax-class
define-splicing-syntax-class
pattern
1.4.1`` Pattern Directives
1.4.2`` Pattern Variables and Attributes
attribute

top← prev up next →

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

> > syntax

> > (define-syntax-class name-id stxclass-option ...
> > stxclass-variant ...+)

> (define-syntax-class (name-id . kw-formals) stxclass-option ...
> stxclass-variant ...+)

> stxclass-option |  | = |  | #:attributes (attr-arity-decl ...)
> |  | | |  | #:description description-expr
> |  | | |  | #:opaque
> |  | | |  | #:commit
> |  | | |  | #:no-delimit-cut
> |  | | |  | #:literals (literal-entry ...)
> |  | | |  | #:literal-sets (literal-set ...)
> |  | | |  | #:conventions (convention-id ...)
> |  | | |  | #:local-conventions (convention-rule ...)
> |  | | |  | #:disable-colon-notation
> attr-arity-decl |  | = |  | attr-name-id
> |  | | |  | (attr-name-id depth)
> stxclass-variant |  | = |  | (pattern syntax-pattern pattern-directive ...)

> | description-expr |  | : |  | (or/c string? #f)

Defines name-id as a syntax class, which encapsulates one or more single-term patterns.

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.

> > syntax

> > (define-splicing-syntax-class name-id stxclass-option ...
> > stxclass-variant ...+)

> (define-splicing-syntax-class (name-id kw-formals) stxclass-option ...
> stxclass-variant ...+)

Defines name-id as a splicing syntax class, analogous to a syntax class but encapsulating head patterns rather than single-term patterns.

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.

> > syntax

> > (pattern syntax-pattern pattern-directive ...)

Used to indicate a variant of a syntax class or splicing syntax class. The variant accepts syntax matching the given syntax pattern with the accompanying pattern directives.

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:

pattern-directive |  | = |  | #:declare pattern-id stxclass maybe-role
|  | | |  | #: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 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.

> > syntax

> > (attribute attr-id)

Returns the value associated with the attribute named attr-id. If attr-id is not bound as an attribute, an error is raised.

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:

> > (define-syntax-class table
> (pattern ((key value) ...)
> #:attr hash
> (for/hash ([k (syntax->datum #'(key ...))]
> [v (syntax->datum #'(value ...))])
> (values k v))))

> > (syntax-parse #'((a 1) (b 2) (c 3))
> [t:table
> (attribute t.hash)])

> '#hash((b . 2) (a . 1) (c . 3))

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.

Examples:

> > (syntax-parse #'((a 1) (b 2) (c 3))
> [t:table
> #'(t.key ...)])

> #<syntax:70:0 (a b c)>

> > (syntax-parse #'((a 1) (b 2) (c 3))
> [t:table
> #'t.hash])

> t.hash: attribute is bound to non-syntax value: '#hash((b .
> 2) (a . 1) (c . 3)) 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:

> > (syntax-parse #'(1 2 3)
> [(~or (x:id ...) _)
> (attribute x)])

> #f

top← prev up next →