The Macrological Fascicle
Editorial conventions
The phrase ‘it is an error’ as traditionally used in Scheme reports has been retired in this fascicle. In its place we have adopted a three-way distinction between requirements on implementations, which should be familiar from the specifications of other languages including Common Lisp and C.
‘Undefined’ behaviour (and similar phrases such as ‘the behaviour is undefined …’) is the direct equivalent of ‘it is an error’ in the R7RS small and R6RS language reports. An implementation is allowed to behave in any way at all if instructed to evaluate code with undefined behaviour; however, implementers should be aware of the R6RS guarantee of ‘safety’, a version of which is expected to be applied to the libraries defined by the R7RS large language reports, including to situations which involve undefined behaviour.
‘Unspecified’ behaviour refers to situations in which the report allows implementations to choose one of a number of behaviours explicitly allowed by the report. Implementations are not required to choose the same option in all circumstances, nor are they required to document their choice.
‘Implementation-specified’ behaviour refers to situations in which the report allows implementations to choose between possible behaviours, but does require conforming implementations to document which behaviour they use.
As in the R7RS small language report, the phrase ‘an error is signalled’ continues to refer to a situation in which an exception is required to be raised.
The R7RS Large Foundations will incorporate a revised version of the
R6RS condition types which is compatible with the error objects defined
by the small language report, but this is not yet specified and will be
included in a future fascicle. However, the phrase ‘it is a syntax
violation’ or ‘a syntax violation is signalled’ means that an exception
is raised with condition type &syntax as in the
R6RS.
The phrase ‘domain error’ (or ‘it is a domain error’) refers to using
a procedure with an argument value which is outside the specified range
of possible values for that argument. It is not yet specified what
concrete action implementations should take in this case in the R7RS
Large Foundations. Preliminarily, implementations are encouraged to
signal an error with condition type &assertion as in
the R6RS, but this is not a requirement. The circumstances, if any, in
which a domain error is required to signal an error will likewise be
established in a future fascicle.
The following variable names are used in the specifications of procedures to imply the type of the argument named by that variable:
| Variable | Type |
|---|---|
| id | identifier |
| proc | procedure |
| stx | syntax object |
| symbol | symbol |
[Editorial note: Cross reference each entry in the right hand column to where that type is defined in the text, where possible. ]
It is a domain error if an argument to any procedure does not match the expected type, whether the expected type is implied by the use of a variable name listed in this table, or named explicitly in the specification text.
The key words ‘must’, ‘must not’, ‘required’, ‘shall’, ‘shall not’, ‘should’, ‘should not’, ‘recommended’, ‘may’, and ‘optional’ in this document, although not capitalized in this report, are to be interpreted as described in RFC 2119. (Bradner 1997)
Comments of the form ‘[Editorial note: ... ]’ are editorial notes marking places requiring revision in the final report.