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 Derick Eddington 12 Aug 2008 01:56 UTC

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