[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revised SRFI-76 (R6RS Records) draft

This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.



Taylor Campbell <campbell@xxxxxxxxxx> writes:

>    Date: Mon, 2 Jan 2006 08:53:59 -0600 (CST)
>    From: Donovan Kolbly <donovan@xxxxxxxxxxx>
>
>    - 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