By Aaron W. Hsu
Current Revision: 7 June 2011
The following record proposal is designed to satisfy the following constraints:
It is designed as a counterpoint to SRFI-9 specifically to alleviate a transition from SRFI-9 and R6RS based code in a WG2 friendly manner without adding any controversial or unnecessary complexity. The design emphasizes a respect for SRFI-9's feature-set while presenting the user and implementor with a more flexible and extensible interface for future extensions, such as implementation extensions or extensions that may be defined by WG2.
SRFI-9 is a well respected and well established de facto standard. With this understanding, this proposal tries to take this into account while improving SRFI-9 in the following ways:
Auxiliary Keyword: fields
Auxiliary Keyword: mutable
Auxiliary Keyword: immutable
The general syntax for define-disjoint-type is as follows:
(define-disjoint-type (name constructor predicate) clause ...)
The clause is one or more record clauses that define features and behaviors of the record. Only one is defined for this proposal, but others may be provided by implementations:
(fields field-spec ...)
Only one fields clause should appear in the list. In a fields clause the field-spec has one of the following forms:
(immutable field-name field-accessor)
(mutable field-name field-accessor field-mutator)
This has the following effect in the scope of the call to define-disjoint-type.
A trivial macro layered over define-disjoint-type is sufficient to make/use SRFI-9 code:(define-syntax define-record-type (syntax-rules (%) [(_ % (name constructor predicate) (cargs ...) ((m fn rest ...) ...) ()) (begin (define-disjoint-type (name %constructor predicate) (fields (m fn rest ...) ...)) (define constructor (let () (define-syntax in-field (syntax-rules (fn ...) [(_ fn) #t] ... [(_ else) #f])) (unless (in-field cargs) (error 'define-record-type "no such field" 'cargs)) ... (lambda (cargs ...) (define-syntax get-val (syntax-rules (cargs ...) [(_ cargs) cargs] ... [(_ filtered) (if #f #f)])) (%constructor (get-val fn) ...)))))] [(_ % bindings cargs (fcs ...) ((fn fa) rest ...)) (define-record-type % bindings cargs (fcs ... (immutable fn fa)) (rest ...))] [(_ % bindings cargs (fcs ...) ((fn fa fm) rest ...)) (define-record-type % bindings cargs (fcs ... (mutable fn fa fm)) (rest ...))] [(_ name (constructor cargs ...) predicate fields ...) (define-record-type % (name constructor predicate) (cargs ...) () (fields ...))]))
See the rationale notes about the filtering constructor for more discussion about this.
Dropping the filtering constructor. The most notable and indeed the most important divergence of this proposal from the core semantics of SRFI-9 is the elimination of the filtering constructor as defined in SRFI-9. This proposal does not preclude extensions which enable a more general functionality, such as R6RS protocols, and other implementation proposals, but it does eliminate a filtering constructor in the way that it is handled by SRFI-9, which is rife with subtle problems.
Problem 1. The filtering constructor provides no means of determining or specifying the default values of the record slots that are not passed values explicitly in the call to the constructor. This requires that all record slots which are to be useful that do not have an explicit constructor field must be mutable, since the only way to fill the record slot with something useful after construction is to mutate the slot. This makes it impossible to have an immutable record slot that is not given an explicit value in the constructor using the filtering constructor mechanism. This is done very often (I use this often to embed things like hidden lookup tables into an object; these lookup tables will never change, and I can get important gains by enforcing immutability on these slots). Instead, if one wishes to achieve this sort of thing, one must avoid the use of the filtering constructor and use an explicit procedure that calls the constructor. This is a much more common case in SRFI-9 usage, and makes the filtering constructor much less useful.
One may also argue that the filtering constructor so used suggests to the user a less functional style in programming, which is arguably less elegant, since other record systems achieve a more general result without requiring mutation.
Problem 2. The filtering constructor is also ill-defined by SRFI-9 as to whether or not field names are matched hygienically or symbolically. In the reference implementation they are matched symbolically, which breaks hygiene and makes the use of SRFI-9 records inside of macros dangerous in combination with filtering constructors. The above implementation that I have provided for SRFI-9 does match field names hygienically, improving the security of the implementation, but this diverges from the reference implementation of SRFI-9. Both SRFI-9 and SRFI-99 share this symbolic equality matching limitation. I do not know whether existing implementations follow the reference implementation in this matter.
Comparison. The above problems are addressed by this proposal in two ways. Firstly, by removing the filtering constructor, no functionality has been lost, but issues with hygiene and mutability have been addressed. The above implementation of SRFI-9 in terms of this proposal demonstrate how the same functionality in SRFI-9 filtering constructors may be achieved with relative ease. Moreover, by removing the filtering constructor, we have removed all situations where it will make a difference whether field names are matched hygienically or symbolically. Since the field-names are not used for anything except place-holders in the current proposal, this means that this issue is effectively side-stepped, and more expansive record systems can deal with the issue explicitly. This reduces complexity of the specification for records in WG1 and makes the overall system simpler.
Lack of inheritance. My initial proposal included a provision for single inheritance. This proposal did not receive enough consensus and lost to SRFI-9. I therefore remove the single inheritance in favor of remaining closer and less divergent from SRFI-9.
Divergence from SRFI-9 syntax. The syntax of this proposal is a very small subset of R6RS. This is a divergence from SRFI-9, but was chosen for particular reasons. Namely, this syntax is much more forward compatible with possible extensions that may be defined by implementations (such as R6RS or WG2 implementations) and it is compatible with existing R6RS record definitions. There is a lot of R6RS code out there.
When choosing a syntax, either SRFI-9 or R6RS, there will be backwards compatibility issues. Those users who use R6RS will be left out if one uses SRFI-9, and those who use R6RS might leave behind those who use SRFI-9. Thus, neither syntax provides inherently better backwards compatibility than the other, since there exist many code repositories with both, sometimes intermingled. The choice to go with the R6RS syntax was made based on its cleanliness and overall elegance in comparison to SRFI-9, not the least of which is the removal of the filtering constructor.
In summary, the SRFI-9 syntax doesn't really gain us that much in backwards compatibility and makes our future compatibilities much more complex. Continuing with the SRFI-9 syntax is very likely to cause us pain in the future and make useful progress more difficult. It is better to have a single syntax framework that enables us to move forward on a single record syntax rather than encouraging implementations and working groups in the future, such as WG2, to diverge from the WG1 record system entirely.
Using the name define-disjoint-type. A major complaint to the R6RS record system was that it used the same name as the SRFI-9 system. In reference to this, I have chosen not to use the define-record-type name so that it does not conflict with either the R6RS syntax or the SRFI-9 implementations. R6RS implementations can support the new syntax by aliasing, while SRFI-9 implementations can continue providing SRFI-9 while also providing this syntax, with translations between the two being straightforward.
Use of keywords for immutability of fields. The use of keywords for fields (whether or not explicitly bound) is in keeping with the R6RS and allows for extensions that improve the brevity of record specifications. These extensions, which are common in implementations, automatically construct the identifiers for accessor and mutators. The keywords provide disambiguation for these situations.
Lack of R6RS name "construction". Many people feel that the construction of identifiers using other identifiers (something that is not possible in pure syntax-rules) is not a good thing. While I have no problem with it, and encourage this extension as an implementation extension, possibly as part of WG2, I recognize that this is something that can be done later, and there is no need to introduce such a controversial feature into the WG1 record system.
Binding of name. The binding of name is to ensure that a certain concept of record semantics common in most systems is available. Most more complete record systems will bind the name, and it is important not to let user's think that they may in fact bind name to something else with the same results. This ensures upwards compatibility with an extended record system provided by WG2.