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