[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Consider a different define-record-type syntax
- To: William D Clinger <will@xxxxxxxxxxx>
- Subject: Re: Consider a different define-record-type syntax
- From: Derick Eddington <derick.eddington@xxxxxxxxx>
- Date: Mon, 11 Aug 2008 18:56:56 -0700
- Cc: srfi-99@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-99@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=vx6H4v5gUvFnucFksIrxEJzVLDvpk34TA12J0u8ySVs=; b=VEFktM/PEHhDoxXvnRISRqa7A4ApUFrpHEPZ+VUYgefM5+i7vgpWomh5trKpClpLOz S7cLG347O/xVz7QlVG0m07pQa/VT6Zxr9dPjDmimEbyRGXvV8/yK1nojeOESdw3JDZKH Rwr1ZNZNFshcQ14Z3X0E8unGHM/d8Kx7FRE/k=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=BDtutpa0+caQkmAR9UNDqkgtUCj0mz+QGF9MkvcKKZcKTvY016dh/pU6Uahv7CzQFa Inio9UAIKdqbjNmElDebz9I+FADjsI1193rygw0NqVp9UD2FSlYH4qWGrUP6CgQV2bi2 xSjjyig4ZvWuJ84LMy60lYlPaqp8hovtEo+4M=
- In-reply-to: <E1KSgZV-0006ms-TE@xxxxxxxxxxxxxxxxx>
- References: <E1KSgZV-0006ms-TE@xxxxxxxxxxxxxxxxx>
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
> 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.
> 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.