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
----------------------------------------------------------------