The current draft of SRFI 237 is insofar feature-complete as everything is expressible with the syntactic form of define-record-type that is defined in the spec.
However, because of the scope of this SRFI, the syntactic form comes in two versions, one based on SRFI 9 and one based on R6RS. The complete feature set is only accessible through the R6RS form, where it is obvious how to extend it with new features syntactically. At least two members of the community, Daphne and John, have voiced their wish to bring the SRFI 9-part on par (except for the implicit introduction of identifiers the R6RS form can do). While not technically necessary and while it has the danger of manifesting the coexistence of two forms, I have agreed to amend the SRFI 9-version to improve acceptance of this SRFI. A few ideas have been exchanged about how such an extension of the SRFI 9-form of define-record-type could look like. John suggested having an augmented plist in place of the record name, like in (define-record-type (colored-pair parent pare nongenerative #t) (make-colored-pair ...) colored-pair? ...) The yet unsolved problem I see with this proposal is how to naturally incorporate non-default protocols (in the sense of the R6RS record facility) into the syntax. With the existing SRFI 9 syntax, the constructor subform "(make-colored-pair ...)" is an exact template for a later constructor call. For example, one would like to retain this. In the SRFI 9 form, the formal arguments refer to field names, but it is unclear how to make any such relation still meaningful in the presence of non-default protocols. Finally, we don't want any extension of the SRFI 9 syntax to be mistaken for a SRFI 99/SRFI 136/SRFI 150 syntax unless its meaning coincides. I have written this long post because I would like to appeal to the community (or at least that part that would prefer a SRFI 9-like syntax) to help me come up with convincing solutions. I don't want to add something half-baked into the final version of this SRFI because this would be of no use to those who want to stick to the SRFI 9 syntax. Semantically, both syntactical versions of the define-record-form have to be compatible, of course, as everything else would be against the spirit of the reconciliation mentioned in this SRFI's title. Thanks for reading, Marc
