[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Consider a different define-record-type syntax

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.

On Mon, 2008-08-11 at 19:13 -0400, William D Clinger wrote:
> 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.

Thanks for the explanation.

> Of
> course, it might be possible to design some less
> annoying extension of SRFI 99 that would satisfy
> the same design goals.

That would be cool.  But if not, it's not a big deal to me because it's
easy enough for me to make my own syntactic layer.

: Derick