Title

ERR5RS Record Syntax (reduced)

Author

John Cowan, Will Clinger

Status

This SRFI is currently in final status. Here is an explanation of each status that a SRFI can hold. To provide input on this SRFI, please send email to srfi-131@nospamsrfi.schemers.org. To subscribe to the list, follow these instructions. You can access previous messages via the mailing list archive.

• Received: 2015-12-07
• 60-day deadline: 2016-02-05
• Draft #1 published: 2015-12-07
• Draft #2 published: 2015-12-17
• Draft #3 published: 2016-02-06
• Finalized: 2016-02-03

Abstract

This SRFI is a reduced version of the SRFI 99 syntactic layer that can be implemented with syntax-rules without requiring low-level macros. Like SRFI-99's syntax layer, it is backward compatible with the define-record-type macro from SRFI 9 or R7RS-small. It is forward compatible with SRFI 99.

Issues

No issues at present.

Rationale

Implementations of Scheme that provide only syntax-rules macros cannot currently implement the syntactic layer of SRFI 99. Three features make a syntax-rules implementation impossible:

• Specifying #t as the constructor name, which is equivalent to specifying the type name prefixed by make-.

• Specifying #t as the predicate name, which is equivalent to specifying the type name suffixed by ?.

• Specifying a field spec as either an identifier or a parenthesized identifier, which are equivalent to specifying an accessor name equivalent to the type name followed by - followed by the field name, and (in the latter case) a mutator name equivalent to the type name followed by - followed by the field name followed by -set!

All of these features violate macro hygiene by introducing identifiers into the code which don't appear in the macro call, which is why syntax-rules will not suffice to implement them. However, they are only notational and can be replaced by explicit equivalents in user code. By eliminating them, as in this SRFI, a pure syntax-rules implementation such as the sample implementation can provide all the other features of SRFI 99's syntactic layer.

Specification

Syntactic Layer

The syntactic layer consists of R7RS define-record-type extended with single inheritance and mechanisms for abstract record types.

The syntax of a record-type definition is:

 <definition>           
   -> <record type definition>

 <record type definition>
   -> (define-record-type <type spec>
        <constructor spec>
        <predicate spec>
        <field spec> ...)

 <type spec>  -> <type name>
              -> (<type name> <parent>)

 <constructor spec>
              -> #f
              -> <constructor name>
              -> (<constructor name> <field name> ...)

 <predicate spec>
              -> #f
              -> <predicate name>

 <field spec> -> (<field name> <accessor name>)
              -> (<field name> <accessor name> <mutator name>)

 <parent>           -> <expression>

 <type name>        -> <identifier>
 <constructor name> -> <identifier>
 <predicate name>   -> <identifier>
 <accessor name>    -> <identifier>
 <mutator name>     -> <identifier>
 <field name>       -> <identifier>

The semantics of a record type definition is the same as in R7RS-small (or SRFI 9, except that record types are generative). The record type definition macro-expands into a cluster of definitions that:

• define the <type name> as the record-type descriptor for the new record-type;
• defines a constructor for instances of the new record-type (unless the constructor spec is #f);
• defines a predicate that recognizes instances of the new record-type and its subtypes (unless the predicate spec is #f);
• defines an accessor for each field name;
• defines a mutator for each mutable field name.

A record type definition extends R7RS-small with the following additional options:

• If a <parent> expression is specified, then it must evaluate to a record-type descriptor that serves as the parent record-type for the record-type being defined.
• If #f is specified for the constructor or predicate, then no constructor or predicate procedure is defined. (This is useful when the record-type being defined will be used as an abstract base class.)
• If the constructor name is specified as an identifier, then the constructor's arguments correspond to the fields of the parent (if any) followed by the new fields added by this record-type definition in the specified order.

When a constructor spec is of the form (<constructor name> <field name> ...):

• Each of the field names can be either a field name declared in the same define-record-type form, or any of its ancestors' field names.
• If the record definition contains the same field name as one of its ancestors, it shadows the ancestor's field name for the purposes of the constructor. The constructor's argument initializes the child's slot, and the ancestor's slot of the same name is left uninitialized.
• It is an error if the same identifier appears more than once in the field names of the constructor spec.

These are not explicit in SRFI 99's syntactic layer section, but can be inferred from its description of the procedural layer.

Implementation

The sample implementation, a single-file R7RS library, is in the code repository of this SRFI. It was written by Will Clinger. It is built on top of the procedural parts of SRFI 99.

Copyright

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.