Revised SRFI-76 (R6RS Records) draft
Donovan Kolbly
(02 Jan 2006 14:54 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Taylor Campbell
(02 Jan 2006 16:28 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft Michael Sperber (03 Jan 2006 17:04 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Taylor Campbell
(03 Jan 2006 21:00 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Michael Sperber
(04 Jan 2006 18:19 UTC)
|
Need to avoid breaking abstractions? Then *DON'T*.
bear
(10 Jan 2006 18:12 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Per Bothner
(03 Jan 2006 21:05 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft Michael Sperber 03 Jan 2006 16:59 UTC
Taylor Campbell <xxxxxx@mumble.net> writes: > Date: Mon, 2 Jan 2006 08:53:59 -0600 (CST) > From: Donovan Kolbly <xxxxxx@rscheme.org> > > - The syntactic form has been renamed to DEFINE-RECORD-TYPE, with > other renames in its wake. > > I think this is a very bad idea. I will never use this SRFI, for its > excessive & unnecessary overcomplexity & overengineering, but it would > be very annoying for it to break all code that uses SRFI 9 by usurping > the name DEFINE-RECORD-TYPE. Now, ermh, we actually did this at *your* suggestion: http://srfi.schemers.org/srfi-76/mail-archive/msg00010.html Quoting you: >> I'd rather see the old name DEFINE-RECORD-TYPE or some variation >> thereof. (... and you weren't the only one who requested the change.) Anyway, I'm as much of a fan of SRFI 9 as you are, but its sheer presence isn't a good argument for hijacking the arguably most natural name for the record-type-defining form. After all, even Scheme 48 comes with two different macors called DEFINE-RECORD-TYPE. The obvious solution is to use a library/module system to distinguish the different ones. > I'd suggest DEFINE-RECORD-TYPE* (though I already use my own (very > much simpler) macro called that), DEFINE-COMPLEX-RECORD-TYPE, or > something along those lines. As we found out in the discussion leading to the draft, for records, many facets of simplicity are in the eye of the beholder. We spent a lof of time trying to make things as simple as we could by meeting the requirements spelled out in the rationale. The current draft is, in many way, already significantly simpler than the previous one, and much closer to the spirit of SRFI 9 when it comes to the constructor mechanism. Record mechanism by nature tend to be amalgams of several features that can be decomposed---SRFI 9 is no different. The reference implementation already tries to present the SRFI in terms of such a decomposition, and I invite you to look at that and comment. If you know a simpler way to define a record-type-defining form that supports inheritance and whatever comes with it, by all means don't hold back. I'd love to make things simpler. (And, I'm sure, so would my co-authors.) I actually asked you to do that here, a while ago: http://srfi.schemers.org/srfi-76/mail-archive/msg00011.html ... but, alas, no reply so far. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla