1.3 Parsing Syntax
This section describes syntax-parse, the
syntax/parse library’s facility for parsing
syntax. Both syntax-parse and the specification facility,
syntax classes, use a common language
of syntax patterns, which is described in detail in
Syntax Patterns.
Two parsing forms are provided: syntax-parse and
syntax-parser.
(syntax-parse stx-expr parse-option ... clause ...+)
|
|
parse-option | | = | | #:context context-expr | | | | | | #:literals (literal ...) | | | | | | #:literal-sets (literal-set ...) | | | | | | #:conventions (convention-id ...) | | | | | | #:local-conventions (convention-rule ...) | | | | | | #:disable-colon-notation | | | | | | literal | | = | | literal-id | | | | | | (pattern-id literal-id) | | | | | | (pattern-id literal-id #:phase phase-expr) | | | | | | literal-set | | = | | literal-set-id | | | | | | (literal-set-id literal-set-option ...) | | | | | | literal-set-option | | = | | #:at context-id | | | | | | #:phase phase-expr | | | | | | clause | | = | | (syntax-pattern pattern-directive ... body ...+) |
|
|
|
Evaluates
stx-expr, which should produce a syntax object, and
matches it against the
clauses in order. If some clause’s
pattern matches, its attributes are bound to the corresponding
subterms of the syntax object and that clause’s side conditions and
expr is evaluated. The result is the result of
expr.
Each clause consists of a syntax pattern, an optional sequence
of pattern directives, and a non-empty sequence of body
forms.
If the syntax object fails to match any of the patterns (or all
matches fail the corresponding clauses’ side conditions), a syntax
error is raised.
The following options are supported:
When present, context-expr is used in reporting parse
failures; otherwise stx-expr is used. The
current-syntax-context parameter is also set to the value of
context-expr.
Examples: |
| a: expected identifier at: 3 | | lambda: expected identifier at: 3 |
|
#:literals (literal ...) |
|
literal | | = | | literal-id | | | | | | (pattern-id literal-id) | | | | | | (pattern-id literal-id #:phase phase-expr) |
|
|
|
Unlike syntax-case, syntax-parse requires all
literals to have a binding. To match identifiers by their symbolic
names, use the ~datum pattern form instead.
The #:literals option specifies identifiers that should be
treated as literals rather than pattern variables. An
entry in the literals list has two components: the identifier used
within the pattern to signify the positions to be matched
(pattern-id), and the identifier expected to occur in those
positions (literal-id). If the entry is a single identifier,
that identifier is used for both purposes.
If the #:phase option is given, then the literal is compared
at phase phase-expr. Specifically, the binding of the
literal-id at phase phase-expr must match the
input’s binding at phase phase-expr.
#:literal-sets (literal-set ...) |
|
literal-set | | = | | literal-set-id | | | | | | (literal-set-id literal-set-option ...) | | | | | | literal-set-option | | = | | #:at lctx | | | | | | #:phase phase-expr |
|
|
|
Many literals can be declared at once via one or more literal
sets, imported with the #:literal-sets option. See
literal sets for more information.
If the #:at keyword is given, the lexical context of the
lctx term is used to determine which identifiers in the
patterns are treated as literals; this option is useful primarily for
macros that generate syntax-parse expressions.
#:conventions (conventions-id ...) |
Imports conventions that give default syntax classes to pattern
variables that do not explicitly specify a syntax class.
#:local-conventions (convention-rule ...) |
Uses the conventions specified. The advantage of
#:local-conventions over #:conventions is that local
conventions can be in the scope of syntax-class parameter
bindings. See the section on conventions for examples.
Suppresses the “colon notation” for annotated pattern variables.
Examples: |
| syntax-parse: not defined as syntax class at: y | | 'ok |
|
Like
syntax-parse, but produces a matching procedure. The
procedure accepts a single argument, which should be a syntax object.
Definition form of
syntax-parse. That is, it matches the
syntax object result of
stx-expr against
syntax-pattern and creates pattern variable definitions for
the attributes of
syntax-pattern.
Examples: |
| > #'(kw ...) | #<syntax:67:0 (#:a #:b #:c)> |
|
Compare with define/with-syntax, a similar definition form
that uses the simpler syntax-case patterns.