This page is part of the web mail archives of SRFI 57 from before July 7th, 2015. The new archives for SRFI 57 contain all messages, not just those from before July 7th, 2015.
At Sun, 12 Sep 2004 16:49:25 -0400 (EDT), Andre van Tonder wrote: > > Hi Jorgen, thanks for your comments > > On Sun, 12 Sep 2004, Jorgen Schaefer wrote: > > > My main problem is the relationship between SRFI-57 and SRFI-9. As > > far as features are concerned, this SRFI looks like a perfect > > extension to SRFI-9, yet it doesn't try to stay compatible with > > SRFI-9. Is there a good reason for changing the argument order and > > makeup of the DEFINE-RECORD macro from that specified in SRFI-9? > > I.e. that the predicate comes last, and that the fields are > > specified as a list of field specifiers instead of specifiers as > > separate arguments? > > So as to permit omissions without running into ambiguities (if you agree > that the possibility of ommissions is a good thing). For > example, with the SRFI-9 order, in > > (define-record foo bar) > > are we omitting the constructor or the predicate, or both (note that > SRFI-57 allows the constructor clause and field clauses to be > identifiers)? We could allow #f in place of the constructor or predicate when you don't want to specify it (I'm pretty sure I've seen a Scheme that does this). > With SRFI-57, we can write > > (define-record foo bar ()) - bar is constructor, no fields or predicate (define-record-type foo bar) > (define-record foo () bar) - bar is predicate, no fields or constructor (define-record-type foo #f bar) There's no ambiguity and we preserve backwards compatibility. In general I agree with Jorgen (and Olin Shivers argument on the original SRFI-9 list) that it would be nice to preserve backwards compatibility where possible. Thus if SRFI-57 uses "define-record-type" and doesn't change the order of parameters, then any existing SRFI-9 code can run unmodified in SRFI-57. True it's just a matter of providing syntax wrappers to define define-record-type in terms of define-record, but you end up with namespace clutter and increasing amounts of legacy wrappers when just a little care in the initial design can obviate the need for this. > ...you have a point. While I specified matching on records (and > only on records - the rest is not required) because without it, records > are much less useful to me, there certainly is a strong argument for > splitting matching off into a separate SRFI, and I *might* do that if I > can summon up the required mixture of masochism and ruthlessness for it. Please do! Your implementation is beautiful, but matching is an entirely orthogonal concept to records and I don't think you should let the implementation influence the design. -- Alex