This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.
Derick Eddington wrote: > It is inconsistent that define-record-type provides succinct <field > spec> which automatically make names for the accessor and mutator but it > requires (annoyingly, not succinctly) using, and remembering to use, #t > #t to get it to automatically make names for the constructor and > predicate. I imagine it's like that to be compatible with SRFI-9, but > how important is that compatibility, i.e., how much will that > compatibility be used into the longer-term future? SRFI 99 was designed to work with the R5RS as well as with ERR5RS and the R6RS. In R5RS code, SRFI 9 is still the dominant record system. Its future importance depends upon the future importance of R5RS code and the IEEE/ANSI/R5RS standards. As you know, the R6RS editors decided that R5RS-style programs and interactive top levels were beyond the scope of the R6RS, so the IEEE/ANSI/R5RS standards remain the relevant standards for programs that are loaded dynamically or developed interactively. I don't see dynamic loading or interactive development becoming markedly less important in the coming years. Although ERR5RS or some successor to the R6RS might supersede the IEEE/ANSI/R5RS standards, there is as yet no indication that such a superseding standard would have a record system that is incompatible with SRFI 9. At the moment, ERR5RS is compatible with SRFI 9. That was one of the design goals for SRFI 99. Of course, it might be possible to design some less annoying extension of SRFI 99 that would satisfy the same design goals. Will