A record is a compound data structure with a fixed number of components, called fields. Each record has an associated type specified by a record-type descriptor, which is an object that specifies the fields of the record and various other properties that all records of that type share. Record objects are created by a record constructor, a procedure that creates a fresh record object and initializes its fields to values. Records of different types can be distinguished from each other and from other types of objects by record predicates. A record predicate returns #t when passed a record of the type specified by the record-type descriptor and #f otherwise. An accessor extracts from a record the component associated with a field, and a mutator changes the component to a different value.
Record types can be extended via single inheritance, allowing record types to model hierarchies that occur in applications like algebraic data types as well as single-inheritance class systems. If a record type t extends another record type p, each record of type t is also a record of type p, and the predicate, accessors, and mutators applicable to a record of type p are also applicable to a record of type t. The extension relationship is transitive in the sense that a type extends its parent’s parent, if any, and so on. A record type that does not extend another record type is called a base record type.
A record type can be sealed to prevent it from being extended. Moreover, a record type can be nongenerative, i.e., it is globally identified by a “uid”, and new, compatible definitions of a nongenerative record type with the same uid as a previous always yield the same record type.
The record mechanism spans three libraries:
the (rnrs records syntactic (6)) library, a syntactic layer for defining a record type and associated constructor, predicate, accessor, and mutators,
the (rnrs records procedural (6)) library, a procedural layer for creating and manipulating record types and creating constructors, predicates, accessors, and mutators;
the (rnrs records inspection (6)) library, a set of inspection procedures.
The inspection procedures allow programs to obtain from a record instance a descriptor for the type and from there obtain access to the fields of the record instance. This facility allows the creation of portable printers and inspectors. A program may prevent access to a record’s type—and thereby protect the information stored in the record from the inspection mechanism—by declaring the type opaque. Thus, opacity as presented here can be used to enforce abstraction barriers.
The procedural layer is particularly useful for writing interpreters that construct host-compatible record types. It may also serve as a target for expansion of the syntactic layers. However, the record operations provided through the procedural layer may be significantly less efficient than the operations provided through the syntactic layer. Therefore, alternative implementations of syntactic record-type definition should, when possible, expand into the syntatic layer rather than the procedural layer.
The syntactic layer is used more commonly and therefore described first. This chapter uses the rtd and constructor-descriptor parameter names for arguments that must be record-type descriptors and constructor descriptors, respectively (see section 6.3).
The fields of a record type are designated mutable or immutable. Correspondingly, a record type with no mutable field is called immutable, and all records of that type are immutable objects. All other record types are mutable, and so are their records.
Each call to a record constructor returns a new record with a fresh location (see report section on “Storage model”). Consequently, for two records obj1 and obj2, the return value of (eqv? obj1 obj2), adheres to the following criteria (see report section on “Equivalence predicates”):
If obj1 and obj2 have different record types (i.e., their record-type descriptors are not eqv?), eqv? returns #f.
If obj1 and obj2 are both records of the same record type, and are the results of two separate calls to record constructors, then eqv? returns #f.
If obj1 and obj2 are both records of the same record type, and both are the result of a single call to a record constructor, then eqv? returns #t.
If obj1 and obj2 are both records of the same record type, where applying an accessor to both yields results for which eqv? returns #f, then eqv? returns #f.
These comments apply as well to eq?, which is guaranteed to have the same behavior on records as eqv?.
The record-type-defining form define-record-type is a definition and can appear anywhere any other <definition> can appear.
A define-record-type form defines a record type along with associated constructor descriptor and constructor, predicate, field accessors, and field mutators. The define-record-type form expands into a set of definitions in the environment where define-record-type appears; hence, it is possible to refer to the bindings (except for that of the record type itself) recursively.
The <name spec> specifies the names of the record type, constructor, and predicate. It must take one of the following forms:
(<record name> <constructor name> <predicate name>)
<Record name>, <constructor name>, and <predicate name> must all be identifiers.
<Record name>, taken as a symbol, becomes the name of the record type. (See the description of make-record-type-descriptor below.) Additionally, it is bound by this definition to an expand-time representation of the record type; it can be used as parent name in syntactic record-type definitions that extend this definition. It can also be used as a handle to gain access to the underlying record-type descriptor and constructor descriptor (see record-type-descriptor and record-constructor-descriptor below).
<Constructor name> is defined by this definition to be a constructor for the defined record type, with a protocol specified by the protocol clause, or, in its absence, using a default protocol. For details, see the description of the protocol clause below.
<Predicate name> is defined by this definition to a predicate for the defined record type.
The second form of <name spec> is an abbreviation for the first form, where the name of the constructor is generated by prefixing the record name with make-, and the predicate name is generated by adding a question mark (?) to the end of the record name. For example, if the record name is frob, the name of the constructor is make-frob, and the predicate name is frob?.
Each <record clause> must take one of the following forms; it is a syntax violation if multiple <record clause>s of the same kind appear in a define-record-type form.
(fields <field spec>*)
Each <field spec> has one of the following forms
(immutable <field name> <accessor name>)
<Field name>, <accessor name>, and <mutator name> must all be identifiers. The first form declares an immutable field called <field name>, with the corresponding accessor named <accessor name>. The second form declares a mutable field called <field name>, with the corresponding accessor named <accessor name>, and with the corresponding mutator named <mutator name>.
If <field spec> takes the third or fourth form, the accessor name is generated by appending the record name and field name with a hyphen separator, and the mutator name (for a mutable field) is generated by adding a -set! suffix to the accessor name. For example, if the record name is frob and the field name is widget, the accessor name is frob-widget and the mutator name is frob-widget-set!.
If <field spec> is just a <field name> form, it is an abbreviation for (immutable <field name>).
The <field name>s become, as symbols, the names of the fields in the record-type descriptor being created, in the same order.
The fields clause may be absent; this is equivalent to an empty fields clause.
(parent <parent name>)
Specifies that the record type is to have parent type <parent name>, where <parent name> is the <record name> of a record type previously defined using define-record-type. The record-type definition associated with <parent name> must not be sealed. If no parent clause and no parent-rtd (see below) clause is present, the record type is a base type.
<Expression> is evaluated in the same environment as the define-record-type form, and must evaluate to a protocol appropriate for the record type being defined.
The protocol is used to create a record-constructor descriptor (see below). If the record type being defined has a parent, the parent-type constructor descriptor is the one associated with the parent type specified in the parent clause. If no protocol clause is specified, a constructor descriptor is still created using a default protocol. The rules for this are the same as for make-record-constructor-descriptor: the clause can be absent only if the record type defined has no parent type, or if the parent definition does not specify a protocol.
If this option is specified with operand #t, the defined record type is sealed, i.e., no extensions of the record type can be created. If this option is specified with operand #f, or is absent, the defined record type is not sealed.
If this option is specified with operand #t, or if an opaque parent record type is specified, the defined record type is opaque. Otherwise, the defined record type is not opaque. See the specification of record-rtd below for details.
This specifies that the record type is nongenerative with uid <uid>, which must be an <identifier>. If <uid> is absent, a unique uid is generated at macro-expansion time. If two record-type definitions specify the same uid, then the record-type definitions should be equivalent, i.e., the implied arguments to make-record-type-descriptor must be equivalent as described under make-record-type-descriptor. If this condition is not met, it is either considered a syntax violation or an exception with condition type &assertion is raised. If the condition is met, a single record type is generated for both definitions.
In the absence of a nongenerative clause, a new record type is generated every time a define-record-type form is evaluated:
(let ((f (lambda (x)
(parent-rtd <parent rtd> <parent cd>)
Specifies that the record type is to have its parent type specified by <parent rtd>, which should be an expression evaluating to a record-type descriptor, and <parent cd>, which should be an expression evaluating to a constructor descriptor (see below). The record-type definition associated with the value of <parent rtd> must not be sealed. Moreover, a record-type definition must not have both a parent and a parent-rtd clause.
Note: Use of the parent-rtd clause generally forces an implementation to delay the generation of constructor, accessor, and mutator code until the record-type definition is evaluated at run time, since the type of the parent is not generally known until then. The parent clause should therefore be used instead whenever possible.
All bindings created by define-record-type (for the record type, the constructor, the predicate, the accessors, and the mutators) must have names that are pairwise distinct.
The constructor created by a define-record-type form is a procedure as follows:
If there is no parent clause and no protocol clause, the constructor accepts as many arguments as there are fields, in the same order as they appear in the fields clause, and returns a record object with the fields initialized to the corresponding arguments.
If there is no parent or parent-rtd clause and a protocol clause, the protocol expressions must evaluate to a procedure that accepts a single argument. The protocol procedure is called once with a procedure p as its argument. It should return a procedure, which will become the constructor bound to <constructor name>. The procedure p accepts as many arguments as there are fields, in the same order as they appear in the fields clause, and returns a record object with the fields initialized to the corresponding arguments.
The constructor returned by the protocol procedure can accept an arbitrary number of arguments, and should call p once to construct a record object, and return that record object.
For example, the following protocol expression for a record-type definition with three fields creates a constructor that accepts values for all fields, and initialized them in the reverse order of the arguments:
If there is both a parent clause and a protocol clause, then the protocol procedure is called once with a procedure n as its argument. As in the previous case, the protocol procedure should return a procedure, which will become the constructor bound to <constructor name>. However, n is different from p in the previous case: It accepts arguments corresponding to the arguments of the constructor of the parent type. It then returns a procedure p that accepts as many arguments as there are (additional) fields in this type, in the same order as in the fields clause, and returns a record object with the fields of the parent record types initialized according to their constructors and the arguments to n, and the fields of this record type initialized to its arguments of p.
The constructor returned by the protocol procedure can accept an arbitrary number of arguments, and should call n once to construct the procedure p, and call p once to create the record object, and finally return that record object.
For example, the following protocol expression assumes that the constructor of the parent type takes three arguments:(lambda (n)
The resulting constructor accepts seven arguments, and initializes the fields of the parent types according to the constructor of the parent type, with v1, v2, and v3 as arguments. It also initializes the fields of this record type to the values of x1, ..., x4.
If there is a parent clause, but no protocol clause, then the parent type must not have a protocol clause itself. The constructor bound to <constructor name> is a procedure that accepts arguments corresponding to the parent types’ constructor first, and then one argument for each field in the same order as in the fields clause. The constructor returns a record object with the fields initialized to the corresponding arguments.
If there is a parent-rtd clause, then the constructor is as with a parent clause, except that the constructor of the parent type is determined by the constructor descriptor of the parent-rtd clause.
A protocol may perform other actions consistent with the requirements described above, including mutation of the new record or other side effects, before returning the reocrd.
Any definition that takes advantage of implicit naming for the constructor, predicate, accessor, and mutator names can be rewritten trivially to a definition that specifies all names explicitly. For example, the implicit-naming record definition:
is equivalent to the following explicit-naming record definition.
(define-record-type (frob make-frob frob?)
Also, the implicit-naming record definition:
(define-record-type point (fields x y))
is equivalent to the following explicit-naming record definition:
(define-record-type (point make-point point?)
With implicit naming, one can choose to specify just some of the names explicitly; for example, the following overrides the choice of accessor and mutator names for the widget field.
Evaluates to the record-type descriptor (see below) associated with the type specified by <record-name>.
Note: The record-type-descriptor procedure works on both opaque and non-opaque record types.
Evaluates to the record-constructor descriptor (see below) associated with <record name>.
(define-record-type (point make-point point?)
The name argument must be a symbol. It names the record type, and is intended purely for informational purposes and may be used for printing by the underlying Scheme system.
The parent argument must be either #f or an rtd. If it is an rtd, the returned record type, t, extends the record type p represented by parent. An exception with condition type &assertion is raised if parent is sealed (see below).
The uid argument must be either #f or a symbol. If uid is a symbol, the record-creation operation is nongenerative i.e., a new record type is created only if no previous call to make-record-type-descriptor was made with the uid. If uid is #f, the record-creation operation is generative, i.e., a new record type is created even if a previous call to make-record-type-descriptor was made with the same arguments.
If make-record-type-descriptor is called twice with the same uid symbol, the parent arguments in the two calls must be eqv?, the fields arguments equal?, the sealed? arguments boolean-equivalent (both #f or both true), and the opaque? arguments boolean-equivalent. If these conditions are not met, an exception with condition type &assertion is raised when the second call occurs. If they are met, the second call returns, without creating a new record type, the same record-type descriptor (in the sense of eqv?) as the first call.
Note: Users are encouraged to use symbol names constructed using the UUID namespace (for example, using the record-type name as a prefix) for the uid argument.
The sealed? flag must be a boolean. If true, the returned record type is sealed, i.e., it cannot be extended.
The opaque? flag must be a boolean. If true, the record type is opaque. If passed an instance of the record type, record? returns #f. Moreover, if record-rtd (see “Inspection” below) is called an instance of the record type, an exception with condition type &assertion is raised. The record type is also opaque if an opaque parent is supplied. If opaque? is #f and an opaque parent is not supplied, the record is not opaque.
The fields argument must be a vector of field specifiers. Each field specifier must be a list of the form (mutable name) or a list of the form (immutable name). Each name must be a symbol and names the corresponding field of the record type; the names need not be distinct. A field identified as mutable may be modified, whereas, when a program attempts to obtain a mutator for a field identified as immutable, an exception with condition type &assertion is raised. Where field order is relevant, e.g., for record construction and field access, the fields are considered to be ordered as specified, although no particular order is required for the actual representation of a record instance.
The specified fields are added to the parent fields, if any, to determine the complete set of fields of the returned record type. If fields is modified after make-record-type has been called, the effect on the returned rtd is unspecified.
A generative record-type descriptor created by a call to make-record-type-descriptor is not eqv? to any record-type descriptor (generative or nongenerative) created by another call to make-record-type-descriptor. A generative record-type descriptor is eqv? only to itself, i.e., (eqv? rtd1 rtd2) iff (eq? rtd1 rtd2). Also, two nongenerative record-type descriptors are eqv? iff they were created by calls to make-record-type-descriptor with the same uid arguments.
Returns #t if the argument is a record-type descriptor, #f otherwise.
Returns a record-constructor descriptor (or constructor descriptor for short) that specifies a record constructor (or constructor for short), that can be used to construct record values of the type specified by rtd, and which can be obtained via record-constructor. A constructor descriptor can also be used to create other constructor descriptors for subtypes of its own record type. Rtd must be a record-type descriptor. Protocolmust be a procedure or #f. If it is #f, a default protocol procedure is supplied.
If protocol is a procedure, it is handled analogously to the protocol expression in a define-record-type form.
If rtd is a base record type and protocol is a procedure, parent-constructor-descriptor must be #f. In this case, protocol it is called by record-constructor with a single argument p. P is a procedure that expects one argument for every field of rtd and returns a record with the fields of rtd initialized to these arguments. The procedure returned by protocol should call p once with the number of arguments it expects and return the resulting record as shown in the simple example below:(lambda (p)
Here, the call to p returns a record whose fields are initialized with the values of v1, v2, and v3. The expression above is equivalent to (lambda (p) p). Note that the procedure returned by protocol is otherwise unconstrained; specifically, it can take any number of arguments.
If rtd is an extension of another record type parent-rtd and protocol is a procedure, parent-constructor-descriptor must be a constructor descriptor of parent-rtd or #f. If parent-constructor-descriptor is a constructor descriptor, protocol it is called by record-constructor with a single argument n, which is a procedure that accepts the same number of arguments as the constructor of parent-constructor-descriptor and returns a procedure p that, when called, constructs the record itself. The p procedure expects one argument for every field of rtd (not including parent fields) and returns a record with the fields of rtd initialized to these arguments, and the fields of parent-rtd and its parents initialized as specified by parent-constructor-descriptor.
The procedure returned by protocol should call n once with the number of arguments it expects, call the procedure p it returns once with the number of arguments it expects and return the resulting record. A simple protocol in this case might be written as follows:(lambda (n)
This passes arguments v1, v2, v3 to n for parent-constructor-descriptor and calls p with x1, ..., x4 to initialize the fields of rtd itself.
Thus, the constructor descriptors for a record type form a sequence of protocols exactly parallel to the sequence of record-type parents. Each constructor descriptor in the chain determines the field values for the associated record type. Child record constructors need not know the number or contents of parent fields, only the number of arguments accepted by the parent constructor.
Protocol may be #f, specifying a default value that accepts one argument for each field of rtd (not including the fields of its parent type, if any). Specifically, if rtd is a base type, the default protocol procedure behaves as if it were (lambda (p) p). If rtd is an extension of another type, then parent-constructor-descriptor must be either #f or itself specify a default constructor. In this case, the default protocol procedure behaves as if it were:(lambda (n)
The resulting constructor accepts one argument for each of the record type’s complete set of fields (including those of the parent record type, the parent’s parent record type, etc.) and returns a record with the fields initialized to those arguments, with the field values for the parent coming before those of the extension in the argument list. (In the example, j is the complete number of fields of the parent type, and k is the number of fields of rtd itself.)
If rtd is an extension of another record type, and parent-constructor-descriptor or protocol is #f, protocol must also be #f, and a default constructor descriptor is as described above is also assumed.
Implementation responsibilities: If protocol is a procedure, the implementation must check the restrictions on it to the extent performed by applying it as described when the constructor is called. An implementation may check whether protocol is an appropriate argument before applying it.
Calls the protocol of constructor-descriptor (as described for make-record-constructor-descriptor) and returns the resulting constructor constructor for records of the record type associated with constructor-descriptor.
Returns a procedure that, given an object obj, returns #t if obj is a record of the type represented by rtd, and #f otherwise.
K must be a valid field index of rtd. The record-accessor procedure returns a one-argument procedure that, given a record of the type represented by rtd, returns the value of the selected field of that record.
The field selected is the one corresponding the kth element (0-based) of the fields argument to the invocation of make-record-type-descriptor that created rtd. Note that k cannot be used to specify a field of any type rtd extends.
If the accessor procedure is given something other than a record of the type represented by rtd, an exception with condition type &assertion is raised. Records of the type represented by rtd include records of extensions of the type represented by rtd.
K must be a valid field index of rtd. The record-mutator procedure returns a two-argument procedure that, given a record r of the type represented by rtd and an object obj, stores obj within the field of r specified by k. The k argument is as in record-accessor. If k specifies an immutable field, an exception with condition type &assertion is raised. The mutator returns unspecified values.
A set of procedures are provided for inspecting records and their record-type descriptors. These procedures are designed to allow the writing of portable printers and inspectors.
On the one hand, record? and record-rtd treat records of opaque record types as if they were not records. On the other hand, the inspection procedures that operate on record-type descriptors themselves are not affected by opacity. In other words, opacity controls whether a program can obtain an rtd from a record. If the program has access to the original rtd via make-record-type-descriptor or record-type-descriptor, it can still make use of the inspection procedures.
Any of the standard types mentioned in this report may or may not be implemented as an opaque record type. Consequently, record?, when applied to an object of one of these types, may return #t. In this case, inspection is possible for these objects.
Returns #t if obj is a record, and its record type is not opaque, and returns #f otherwise.
Returns the rtd representing the type of record if the type is not opaque. The rtd of the most precise type is returned; that is, the type t such that record is of type t but not of any type that extends t. If the type is opaque, an exception is raised with condition type &assertion.
Returns the name of the record-type descriptor rtd.
Returns the parent of the record-type descriptor rtd, or #f if it has none.
Returns the uid of the record-type descriptor rtd, or #f if it has none. (An implementation may assign a generated uid to a record type even if the type is generative, so the return of a uid does not necessarily imply that the type is nongenerative.)
Returns #t if rtd is generative, and #f if not.
Returns a boolean value indicating whether the record-type descriptor is sealed.
Returns a boolean value indicating whether the record-type descriptor is opaque.
Returns a vector of symbols naming the fields of the type represented by rtd (not including the fields of parent types) where the fields are ordered as described under make-record-type-descriptor. The returned vector may be immutable. If the returned vector is modified, the effect on rtd is unspecified.
Returns a boolean value indicating whether the field specified by k of the type represented by rtd is mutable, where k is as in record-accessor.