Email list hosting service & mailing list manager

Re: Consider a different define-record-type syntax William D Clinger (11 Aug 2008 23:13 UTC)
Re: Consider a different define-record-type syntax Derick Eddington (12 Aug 2008 01:57 UTC)

Re: Consider a different define-record-type syntax William D Clinger 11 Aug 2008 23:13 UTC

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

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

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.