Expression types are categorized as primitive or derived. Primitive expression types include variables and procedure calls. Derived expression types are not semantically primitive, but can instead be defined as macros. Suitable syntax definitions of some of the derived expressions are given in section 7.3.
The procedures force, promise?, make-promise, and make-parameter are also described in this chapter because they are intimately associated with the delay, delay-force, and parameterize expression types.
An expression consisting of a variable(section 3.1) is a variable reference. The value of the variable reference is the value stored in the location to which the variable is bound. It is an error to reference an unboundvariable.
(define x 28)
(quote <datum>) evaluates to <datum>.<Datum> can be any external representation of a Scheme object (see section 3.3). This notation is used to include literal constants in Scheme code.
(quote a) ⟹ a
'a ⟹ a
'145932 ⟹ 145932
A procedure call is written by enclosing in parentheses an expression for the procedure to be called followed by expressions for the arguments to be passed to it. The operator and operand expressions are evaluated (in an unspecified order) and the resulting procedure is passed the resulting arguments.
(+ 3 4) ⟹ 7Procedure calls can return any number of values (see values in section 6.10). Most of the procedures defined in this report return one value or, for procedures such as apply, pass on the values returned by a call to one of their arguments. Exceptions are noted in the individual descriptions.
Note: In contrast to other dialects of Lisp, the order of evaluation is unspecified, and the operator expression and the operand expressions are always evaluated with the same evaluation rules.
Note: Although the order of evaluation is otherwise unspecified, the effect of any concurrent evaluation of the operator and operand expressions is constrained to be consistent with some sequential order of evaluation. The order of evaluation may be chosen differently for each procedure call.
Note: In many dialects of Lisp, the empty list, (), is a legitimate expression evaluating to itself. In Scheme, it is an error.
Syntax: <Formals> is a formal arguments list as described below, and <body> is a sequence of zero or more definitions followed by one or more expressions.
Semantics: A lambda expression evaluates to a procedure. The environment in effect when the lambda expression was evaluated is remembered as part of the procedure. When the procedure is later called with some actual arguments, the environment in which the lambda expression was evaluated will be extended by binding the variables in the formal argument list to fresh locations, and the corresponding actual argument values will be stored in those locations. (A fresh location is one that is distinct from every previously existing location.) Next, the expressions in the body of the lambda expression (which, if it contains definitions, represents a letrec* form — see section 4.2.2) will be evaluated sequentially in the extended environment. The results of the last expression in the body will be returned as the results of the procedure call.
(lambda (x) (+ x x)) ⟹ a procedure
(<variable1> …): The procedure takes a fixed number of arguments; when the procedure is called, the arguments will be stored in fresh locations that are bound to the corresponding variables.
<variable>: The procedure takes any number of arguments; when the procedure is called, the sequence of actual arguments is converted into a newly allocated list, and the list is stored in a fresh location that is bound to <variable>.
(<variable1> … <variablen> . <variablen+1>): If a space-delimited period precedes the last variable, then the procedure takes n or more arguments, where n is the number of formal arguments before the period (it is an error if there is not at least one). The value stored in the binding of the last variable will be a newly allocated list of the actual arguments left over after all the other actual arguments have been matched up against the other formal arguments.
It is an error for a <variable> to appear more than once in <formals>.
((lambda x x) 3 4 5 6) ⟹ (3 4 5 6)
Each procedure created as the result of evaluating a lambda expression is (conceptually) tagged with a storage location, in order to make eqv? and eq? work on procedures (see section 6.1).
Syntax: <Test>, <consequent>, and <alternate> are expressions.
Semantics: An if expression is evaluated as follows: first, <test> is evaluated. If it yields a true value(see section 6.3), then <consequent> is evaluated and its values are returned. Otherwise <alternate> is evaluated and its values are returned. If <test> yields a false value and no <alternate> is specified, then the result of the expression is unspecified.
(if (> 3 2) 'yes 'no) ⟹ yes
Semantics: <Expression> is evaluated, and the resulting value is stored in the location to which <variable> is bound. It is an error if <variable> is not bound either in some regionenclosing the set! expression or else globally. The result of the set! expression is unspecified.
(define x 2)
Semantics: Both include and include-ci take one or more filenames expressed as string literals, apply an implementation-specific algorithm to find corresponding files, read the contents of the files in the specified order as if by repeated applications of read, and effectively replace the include or include-ci expression with a begin expression containing what was read from the files. The difference between the two is that include-ci reads each file as if it began with the #!fold-case directive, while include does not.
Note: Implementations are encouraged to search for files in the directory which contains the including file, and to provide a way for users to specify other directories to search.
The constructs in this section are hygienic, as discussed in section 4.3. For reference purposes, section 7.3 gives syntax definitions that will convert most of the constructs described in this section into the primitive constructs described in the previous section.
Syntax: <Clauses> take one of two forms, either
(<test> <expression1> …)where <test> is any expression, or (<test> => <expression>)The last <clause> can be an “else clause,” which has the form (else <expression1> <expression2> …).Semantics: A cond expression is evaluated by evaluating the <test> expressions of successive <clause>s in order until one of them evaluates to a true value(see section 6.3). When a <test> evaluates to a true value, the remaining <expression>s in its <clause> are evaluated in order, and the results of the last <expression> in the <clause> are returned as the results of the entire cond expression.
If the selected <clause> contains only the <test> and no <expression>s, then the value of the <test> is returned as the result. If the selected <clause> uses the => alternate form, then the <expression> is evaluated. It is an error if its value is not a procedure that accepts one argument. This procedure is then called on the value of the <test> and the values returned by this procedure are returned by the cond expression.
If all <test>s evaluate to #f, and there is no else clause, then the result of the conditional expression is unspecified; if there is an else clause, then its <expression>s are evaluated in order, and the values of the last one are returned.
(cond ((> 3 2) 'greater)
Syntax: <Key> can be any expression. Each <clause> has the form
((<datum1> …) <expression1> <expression2> …),where each <datum> is an external representation of some object. It is an error if any of the <datum>s are the same anywhere in the expression. Alternatively, a <clause> can be of the form ((<datum1> …) => <expression>)The last <clause> can be an “else clause,” which has one of the forms (else <expression1> <expression2> …)Semantics: A case expression is evaluated as follows. <Key> is evaluated and its result is compared against each <datum>. If the result of evaluating <key> is the same (in the sense of eqv?; see section 6.1) to a <datum>, then the expressions in the corresponding <clause> are evaluated in order and the results of the last expression in the <clause> are returned as the results of the case expression.
If the result of evaluating <key> is different from every <datum>, then if there is an else clause, its expressions are evaluated and the results of the last are the results of the case expression; otherwise the result of the case expression is unspecified.
If the selected <clause> or else clause uses the => alternate form, then the <expression> is evaluated. It is an error if its value is not a procedure accepting one argument. This procedure is then called on the value of the <key> and the values returned by this procedure are returned by the case expression.
(case (* 2 3)
Semantics: The <test> expressions are evaluated from left to right, and if any expression evaluates to #f (see section 6.3), then #f is returned. Any remaining expressions are not evaluated. If all the expressions evaluate to true values, the values of the last expression are returned. If there are no expressions, then #t is returned.
(and (= 2 2) (> 2 1)) ⟹ #t
Semantics: The <test> expressions are evaluated from left to right, and the value of the first expression that evaluates to a true value (see section 6.3) is returned. Any remaining expressions are not evaluated. If all expressions evaluate to #f or if there are no expressions, then #f is returned.
(or (= 2 2) (> 2 1)) ⟹ #t
Syntax: The <test> is an expression.
Semantics: The test is evaluated, and if it evaluates to a true value, the expressions are evaluated in order. The result of the when expression is unspecified.
(when (= 1 1.0)
Syntax: The <test> is an expression.
Semantics: The test is evaluated, and if it evaluates to #f, the expressions are evaluated in order. The result of the unless expression is unspecified.
(unless (= 1 1.0)
Syntax: The cond-expand expression type provides a way to statically expand different expressions depending on the implementation. A <ce-clause> takes the following form:
(<feature requirement> <expression> …)
The last clause can be an “else clause,” which has the form
(else <expression> …)
A <feature requirement> takes one of the following forms:
<feature identifier>
(library <library name>)
(and <feature requirement> …)
(or <feature requirement> …)
(not <feature requirement>)
Semantics: Each implementation maintains a list of feature identifiers which are present, as well as a list of libraries which can be imported. The value of a <feature requirement> is determined by replacing each <feature identifier> and (library <library name>) on the implementation’s lists with #t, and all other feature identifiers and library names with #f, then evaluating the resulting expression as a Scheme boolean expression under the normal interpretation of and, or, and not.
A cond-expand is then expanded by evaluating the <feature requirement>s of successive <ce-clause>s in order until one of them returns #t. When a true clause is found, the corresponding <expression>s are expanded to a begin, and the remaining clauses are ignored. If none of the <feature requirement>s evaluate to #t, then if there is an else clause, its <expression>s are included. Otherwise, the behavior of the cond-expand is unspecified. Unlike cond, cond-expand does not depend on the value of any variables.
The exact features provided are implementation-defined, but for portability a core set of features is given in appendix B.
The binding constructs let, let*, letrec, letrec*, let-values, and let*-values give Scheme a block structure, like Algol 60. The syntax of the first four constructs is identical, but they differ in the regionsthey establish for their variable bindings. In a let expression, the initial values are computed before any of the variables become bound; in a let* expression, the bindings and evaluations are performed sequentially; while in letrec and letrec* expressions, all the bindings are in effect while their initial values are being computed, thus allowing mutually recursive definitions. The let-values and let*-values constructs are analogous to let and let* respectively, but are designed to handle multiple-valued expressions, binding different identifiers to the returned values.
Syntax: <Bindings> has the form
((<variable1> <init1>) …),where each <init> is an expression, and <body> is a sequence of zero or more definitions followed by a sequence of one or more expressions as described in section 4.1.4. It is an error for a <variable> to appear more than once in the list of variables being bound.Semantics: The <init>s are evaluated in the current environment (in some unspecified order), the <variable>s are bound to fresh locations holding the results, the <body> is evaluated in the extended environment, and the values of the last expression of <body> are returned. Each binding of a <variable> has <body> as its region.
(let ((x 2) (y 3))
Syntax: <Bindings> has the form
((<variable1> <init1>) …),and <body> is a sequence of zero or more definitions followed by one or more expressions as described in section 4.1.4.Semantics: The let* binding construct is similar to let, but the bindings are performed sequentially from left to right, and the regionof a binding indicated by (<variable> <init>) is that part of the let* expression to the right of the binding. Thus the second binding is done in an environment in which the first binding is visible, and so on. The <variable>s need not be distinct.
(let ((x 2) (y 3))
Syntax: <Bindings> has the form
((<variable1> <init1>) …),and <body> is a sequence of zero or more definitions followed by one or more expressions as described in section 4.1.4. It is an error for a <variable> to appear more than once in the list of variables being bound.Semantics: The <variable>s are bound to fresh locations holding unspecified values, the <init>s are evaluated in the resulting environment (in some unspecified order), each <variable> is assigned to the result of the corresponding <init>, the <body> is evaluated in the resulting environment, and the values of the last expression in <body> are returned. Each binding of a <variable> has the entire letrec expression as its region, making it possible to define mutually recursive procedures.
(letrec ((even?
Syntax: <Bindings> has the form
((<variable1> <init1>) …),and <body>is a sequence of zero or more definitions followed by one or more expressions as described in section 4.1.4. It is an error for a <variable> to appear more than once in the list of variables being bound.Semantics: The <variable>s are bound to fresh locations, each <variable> is assigned in left-to-right order to the result of evaluating the corresponding <init> (interleaving evaluations and assignments), the <body> is evaluated in the resulting environment, and the values of the last expression in <body> are returned. Despite the left-to-right evaluation and assignment order, each binding of a <variable> has the entire letrec* expression as its region, making it possible to define mutually recursive procedures.
If it is not possible to evaluate each <init> without assigning or referring to the value of the corresponding <variable> or the <variable> of any of the bindings that follow it in <bindings>, it is an error. Another restriction is that it is an error to invoke the continuation of an <init> more than once.
;; Returns the arithmetic, geometric, and
Syntax: <Mv binding spec> has the form
((<formals1> <init1>) …), where each <init> is an expression, and <body> is zero or more definitions followed by a sequence of one or more expressions as described in section 4.1.4. It is an error for a variable to appear more than once in the set of <formals>.Semantics: The <init>s are evaluated in the current environment (in some unspecified order) as if by invoking call-with-values, and the variables occurring in the <formals> are bound to fresh locations holding the values returned by the <init>s, where the <formals> are matched to the return values in the same way that the <formals> in a lambda expression are matched to the arguments in a procedure call. Then, the <body> is evaluated in the extended environment, and the values of the last expression of <body> are returned. Each binding of a <variable> has <body> as its region.
It is an error if the <formals> do not match the number of values returned by the corresponding <init>.
(let-values (((root rem) (exact-integer-sqrt 32)))
Syntax: <Mv binding spec> has the form
((<formals> <init>) …),and <body> is a sequence of zero or more definitions followed by one or more expressions as described in section 4.1.4. In each <formals>, it is an error if any variable appears more than once.Semantics: The let*-values construct is similar to let-values, but the <init>s are evaluated and bindings created sequentially from left to right, with the region of the bindings of each <formals> including the <init>s to its right as well as <body>. Thus the second <init> is evaluated in an environment in which the first set of bindings is visible and initialized, and so on.
(let ((a 'a) (b 'b) (x 'x) (y 'y))
Both of Scheme’s sequencing constructs are named begin, but the two have slightly different forms and uses:
This form of begin can appear as part of a <body>, or at the outermost level of a <program>, or at the REPL, or directly nested in a begin that is itself of this form. It causes the contained expressions and definitions to be evaluated exactly as if the enclosing begin construct were not present.
Rationale: This form is commonly used in the output of macros (see section 4.3) which need to generate multiple definitions and splice them into the context in which they are expanded.
This form of begin can be used as an ordinary expression. The <expression>s are evaluated sequentially from left to right, and the values of the last <expression> are returned. This expression type is used to sequence side effects such as assignments or input and output.
(define x 0)
Note that there is a third form of begin used as a library declaration: see section 5.6.1.
Syntax: All of <init>, <step>, <test>, and <command> are expressions.
Semantics: A do expression is an iteration construct. It specifies a set of variables to be bound, how they are to be initialized at the start, and how they are to be updated on each iteration. When a termination condition is met, the loop exits after evaluating the <expression>s.
A do expression is evaluated as follows: The <init> expressions are evaluated (in some unspecified order), the <variable>s are bound to fresh locations, the results of the <init> expressions are stored in the bindings of the <variable>s, and then the iteration phase begins.
Each iteration begins by evaluating <test>; if the result is false (see section 6.3), then the <command> expressions are evaluated in order for effect, the <step> expressions are evaluated in some unspecified order, the <variable>s are bound to fresh locations, the results of the <step>s are stored in the bindings of the <variable>s, and the next iteration begins.
If <test> evaluates to a true value, then the <expression>s are evaluated from left to right and the values of the last <expression> are returned. If no <expression>s are present, then the value of the do expression is unspecified.
The regionof the binding of a <variable> consists of the entire do expression except for the <init>s. It is an error for a <variable> to appear more than once in the list of do variables.
A <step> can be omitted, in which case the effect is the same as if (<variable> <init> <variable>) had been written instead of (<variable> <init>).
(do ((vec (make-vector 5))
Semantics: “Named let” is a variant on the syntax of let which provides a more general looping construct than do and can also be used to express recursion. It has the same syntax and semantics as ordinary let except that <variable> is bound within <body> to a procedure whose formal arguments are the bound variables and whose body is <body>. Thus the execution of <body> can be repeated by invoking the procedure named by <variable>.
(let loop ((numbers '(3 -2 1 6 -5))
Semantics: The delay construct is used together with the procedure force to implement lazy evaluation or call by need. (delay <expression>) returns an object called a promise which at some point in the future can be asked (by the force procedure) to evaluate <expression>, and deliver the resulting value. The effect of <expression> returning multiple values is unspecified.
Semantics: The expression (delay-force
expression) is conceptually similar to (delay (force
expression)), with the difference that forcing the result of delay-force will in effect result in a tail call to (force
expression), while forcing the result of (delay (force
expression)) might not. Thus iterative lazy algorithms that might result in a long series of chains of delay and force can be rewritten using delay-force to prevent consuming unbounded space during evaluation.
The force procedure forces the value of a
promise created by delay, delay-force, or make-promise.If no value has been computed for the promise, then a value is computed and returned. The value of the promise must be cached (or “memoized”) so that if it is forced a second time, the previously computed value is returned. Consequently, a delayed expression is evaluated using the parameter values and exception handler of the call to force which first requested its value. If
promise is not a promise, it may be returned unchanged.
(force (delay (+ 1 2))) ⟹ 3
(define (stream-filter p? s)
(define count 0)
Calling force on an object that is not a promise may simply return the object.
It may be the case that there is no means by which a promise can be operationally distinguished from its forced value. That is, expressions like the following may evaluate to either #t or to #f, depending on the implementation:
(eqv? (delay 1) 1) ⟹ unspecified
Implementations may implement “implicit forcing,” where the value of a promise is forced by procedures that operate only on arguments of a certain type, like cdr and *. However, procedures that operate uniformly on their arguments, like list, must not force them.
(+ (delay (* 3 7)) 13) ⟹ unspecified
The promise? procedure returns #t if its argument is a promise, and #f otherwise. Note that promises are not necessarily disjoint from other Scheme types such as procedures.
The make-promise procedure returns a promise which, when forced, will return
obj. It is similar to delay, but does not delay its argument: it is a procedure rather than syntax. If
obj is already a promise, it is returned.
The dynamic extent of a procedure call is the time between when it is initiated and when it returns. In Scheme, call-with-current-continuation (section 6.10) allows reentering a dynamic extent after its procedure call has returned. Thus, the dynamic extent of a call might not be a single, continuous time period.
This sections introduces parameter objects, which can be bound to new values for the duration of a dynamic extent. The set of all parameter bindings at a given time is called the dynamic environment.
Returns a newly allocated parameter object, which is a procedure that accepts zero arguments and returns the value associated with the parameter object. Initially, this value is the value of (
converter
init), or of
init if the conversion procedure
converter is not specified. The associated value can be temporarily changed using parameterize, which is described below.
The effect of passing arguments to a parameter object is implementation-dependent.
Syntax: Both <param1> and <value1> are expressions.
It is an error if the value of any <param> expression is not a parameter object.
Semantics: A parameterize expression is used to change the values returned by specified parameter objects during the evaluation of the body.
The <param> and <value> expressions are evaluated in an unspecified order. The <body> is evaluated in a dynamic environment in which calls to the parameters return the results of passing the corresponding values to the conversion procedure specified when the parameters were created. Then the previous values of the parameters are restored without passing them to the conversion procedure. The results of the last expression in the <body> are returned as the results of the entire parameterize expression.
Note: If the conversion procedure is not idempotent, the results of (parameterize ((x (x))) ...), which appears to bind the parameterIf an implementation supports multiple threads of execution, then parameterize must not change the associated values of any parameters in any thread other than the current thread and threads created inside <body>.x to its current value, might not be what the user expects.
Parameter objects can be used to specify configurable settings for a computation without the need to pass the value to every procedure in the call chain explicitly.
(define radix
Syntax: Each <cond clause> is as in the specification of cond.
Semantics: The <body> is evaluated with an exception handler that binds the raised object (see raise in section 6.11) to <variable> and, within the scope of that binding, evaluates the clauses as if they were the clauses of a cond expression. That implicit cond expression is evaluated with the continuation and dynamic environment of the guard expression. If every <cond clause>’s <test> evaluates to #f and there is no else clause, then raise-continuable is invoked on the raised object within the dynamic environment of the original call to raise or raise-continuable, except that the current exception handler is that of the guard expression.
See section 6.11 for a more complete discussion of exceptions.
(guard (condition
“Quasiquote”expressions are useful for constructing a list or vector structure when some but not all of the desired structure is known in advance. If no commasappear within the <qq template>, the result of evaluating `<qq template> is equivalent to the result of evaluating '<qq template>. If a commaappears within the <qq template>, however, the expression following the comma is evaluated (“unquoted”) and its result is inserted into the structure instead of the comma and the expression. If a comma appears followed without intervening whitespace by a commercial at-sign (﹫),then it is an error if the following expression does not evaluate to a list; the opening and closing parentheses of the list are then “stripped away” and the elements of the list are inserted in place of the comma at-sign expression sequence. A comma at-sign normally appears only within a list or vector <qq template>.
Note: In order to unquote an identifier beginning with @, it is necessary to use either an explicit unquote or to put whitespace after the comma, to avoid colliding with the comma at-sign sequence.`(list ,(+ 1 2) 4) ⟹ (list 3 4)
`(a `(b ,(+ 1 2) ,(foo ,(+ 1 3) d) e) f)
(let ((a 3)) `((1 2) ,a ,4 ,'five 6)) may be treated as equivalent to either of the following expressions:
`((1 2) 3 4 five 6)
(let ((a 3)) (list (list 1 2) a 4 'five 6)) The two notations `<qq template> and (quasiquote <qq template>) are identical in all respects. ,<expression> is identical to (unquote <expression>), and ,@<expression> is identical to (unquote-splicing <expression>). The write procedure may output either format.
(quasiquote (list (unquote (+ 1 2)) 4))
It is an error if any of the identifiers quasiquote, unquote, or unquote-splicing appear in positions within a <qq template> otherwise than as described above.
Syntax: Each <clause> is of the form (<formals> <body>), where <formals> and <body> have the same syntax as in a lambda expression.
Semantics: A case-lambda expression evaluates to a procedure that accepts a variable number of arguments and is lexically scoped in the same manner as a procedure resulting from a lambda expression. When the procedure is called, the first <clause> for which the arguments agree with <formals> is selected, where agreement is specified as for the <formals> of a lambda expression. The variables of <formals> are bound to fresh locations, the values of the arguments are stored in those locations, the <body> is evaluated in the extended environment, and the results of <body> are returned as the results of the procedure call.
It is an error for the arguments not to agree with the <formals> of any <clause>.
(define range
Scheme programs can define and use new derived expression types, called macros.Program-defined expression types have the syntax
(<keyword> <datum> ...)where <keyword> is an identifier that uniquely determines the expression type. This identifier is called the syntactic keyword, or simply keyword, of the macro. The number of the <datum>s, and their syntax, depends on the expression type.Each instance of a macro is called a useof the macro. The set of rules that specifies how a use of a macro is transcribed into a more primitive expression is called the transformerof the macro.
The macro definition facility consists of two parts:
A set of expressions used to establish that certain identifiers are macro keywords, associate them with macro transformers, and control the scope within which a macro is defined, and
a pattern language for specifying macro transformers.
The syntactic keyword of a macro can shadow variable bindings, and local variable bindings can shadow syntactic bindings. Two mechanisms are provided to prevent unintended conflicts:
If a macro transformer inserts a binding for an identifier (variable or keyword), the identifier will in effect be renamed throughout its scope to avoid conflicts with other identifiers. Note that a global variable definition may or may not introduce a binding; see section 5.3.
If a macro transformer inserts a free reference to an identifier, the reference refers to the binding that was visible where the transformer was specified, regardless of any local bindings that surround the use of the macro.
In consequence, all macros defined using the pattern language are “hygienic” and “referentially transparent” and thus preserve Scheme’s lexical scoping. [21, 22, 2, 9, 12]
Implementations may provide macro facilities of other types.
The let-syntax and letrec-syntax binding constructs are analogous to let and letrec, but they bind syntactic keywords to macro transformers instead of binding variables to locations that contain values. Syntactic keywords can also be bound globally or locally with define-syntax; see section 5.4.
Syntax: <Bindings> has the form
((<keyword> <transformer spec>) …)Each <keyword> is an identifier, each <transformer spec> is an instance of syntax-rules, and <body> is a sequence of zero or more definitions followed by one or more expressions. It is an error for a <keyword> to appear more than once in the list of keywords being bound.Semantics: The <body> is expanded in the syntactic environment obtained by extending the syntactic environment of the let-syntax expression with macros whose keywords are the <keyword>s, bound to the specified transformers. Each binding of a <keyword> has <body> as its region.
(let-syntax ((given-that (syntax-rules ()
Syntax: Same as for let-syntax.
Semantics: The <body> is expanded in the syntactic environment obtained by extending the syntactic environment of the letrec-syntax expression with macros whose keywords are the <keyword>s, bound to the specified transformers. Each binding of a <keyword> has the <transformer spec>s as well as the <body> within its region, so the transformers can transcribe expressions into uses of the macros introduced by the letrec-syntax expression.
(letrec-syntax
A <transformer spec> has one of the following forms:
Syntax: It is an error if any of the <pattern literal>s, or the <ellipsis> in the second form, is not an identifier. It is also an error if <syntax rule> is not of the form
(<pattern> <template>)The <pattern> in a <syntax rule> is a list <pattern> whose first element is an identifier.A <pattern> is either an identifier, a constant, or one of the following
(<pattern> …)Semantics: An instance of syntax-rules produces a new macro transformer by specifying a sequence of hygienic rewrite rules. A use of a macro whose keyword is associated with a transformer specified by syntax-rules is matched against the patterns contained in the <syntax rule>s, beginning with the leftmost <syntax rule>. When a match is found, the macro use is transcribed hygienically according to the template.
An identifier appearing within a <pattern> can be an underscore (_), a literal identifier listed in the list of <pattern literal>s, or the <ellipsis>. All other identifiers appearing within a <pattern> are pattern variables.
The keyword at the beginning of the pattern in a <syntax rule> is not involved in the matching and is considered neither a pattern variable nor a literal identifier.
Pattern variables match arbitrary input elements and are used to refer to elements of the input in the template. It is an error for the same pattern variable to appear more than once in a <pattern>.
Underscores also match arbitrary input elements but are not pattern variables and so cannot be used to refer to those elements. If an underscore appears in the <pattern literal>s list, then that takes precedence and underscores in the <pattern> match as literals. Multiple underscores can appear in a <pattern>.
Identifiers that appear in (<pattern literal> …) are interpreted as literal identifiers to be matched against corresponding elements of the input. An element in the input matches a literal identifier if and only if it is an identifier and either both its occurrence in the macro expression and its occurrence in the macro definition have the same lexical binding, or the two identifiers are the same and both have no lexical binding.
A subpattern followed by <ellipsis> can match zero or more elements of the input, unless <ellipsis> appears in the <pattern literal>s, in which case it is matched as a literal.
More formally, an input expression E matches a pattern P if and only if:
P is an underscore (_).
P is a non-literal identifier; or
P is a literal identifier and E is an identifier with the same binding; or
P is a list (P1 … Pn) and E is a list of n elements that match P1 through Pn, respectively; or
P is an improper list (P1 P2 … Pn . Pn+1) and E is a list or improper list of n or more elements that match P1 through Pn, respectively, and whose nth tail matches Pn+1; or
P is of the form (P1 … Pk Pe <ellipsis> Pm+1 … Pn) where E is a proper list of n elements, the first k of which match P1 through Pk, respectively, whose next m−k elements each match Pe, whose remaining n−m elements match Pm+1 through Pn; or
P is of the form (P1 … Pk Pe <ellipsis> Pm+1 … Pn . Px) where E is a list or improper list of n elements, the first k of which match P1 through Pk, whose next m−k elements each match Pe, whose remaining n−m elements match Pm+1 through Pn, and whose nth and final cdr matches Px; or
P is a vector of the form #(P1 … Pn) and E is a vector of n elements that match P1 through Pn; or
P is of the form #(P1 … Pk Pe <ellipsis> Pm+1 …Pn) where E is a vector of n elements the first k of which match P1 through Pk, whose next m−k elements each match Pe, and whose remaining n−m elements match Pm+1 through Pn; or
P is a constant and E is equal to P in the sense of the equal? procedure.
It is an error to use a macro keyword, within the scope of its binding, in an expression that does not match any of the patterns.
When a macro use is transcribed according to the template of the matching <syntax rule>, pattern variables that occur in the template are replaced by the elements they match in the input. Pattern variables that occur in subpatterns followed by one or more instances of the identifier <ellipsis> are allowed only in subtemplates that are followed by as many instances of <ellipsis>. They are replaced in the output by all of the elements they match in the input, distributed as indicated. It is an error if the output cannot be built up as specified.
Identifiers that appear in the template but are not pattern variables or the identifier <ellipsis> are inserted into the output as literal identifiers. If a literal identifier is inserted as a free identifier then it refers to the binding of that identifier within whose scope the instance of syntax-rules appears. If a literal identifier is inserted as a bound identifier then it is in effect renamed to prevent inadvertent captures of free identifiers.
A template of the form (<ellipsis> <template>) is identical to <template>, except that ellipses within the template have no special meaning. That is, any ellipses contained within <template> are treated as ordinary identifiers. In particular, the template (<ellipsis> <ellipsis>) produces a single <ellipsis>. This allows syntactic abstractions to expand into code containing ellipses.
(define-syntax be-like-begin
(let ((=> #f))
(let ((=> #f))
(let ((=> #f))
syntax-error behaves similarly to error (6.11) except that implementations with an expansion pass separate from evaluation should signal an error as soon as syntax-error is expanded. This can be used as a syntax-rules <template> for a <pattern> that is an invalid use of the macro, which can provide more descriptive error messages. <message> is a string literal, and <args> arbitrary expressions providing additional information. Applications cannot count on being able to catch syntax errors with exception handlers or guards.
(define-syntax simple-let