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



   Date: Tue, 03 Jan 2006 17:59:48 +0100
   From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>

   Taylor Campbell <campbell@xxxxxxxxxx> writes:

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

Actually, my next sentence was a suggestion that the SRFI 9 syntax
remain supported, which, as far as I can tell, is not the case.  I do
concede, though, that I had totally forgotten that mail I had sent,
and that it wasn't entirely clear to begin with...

I'll respect that there are a lot of complex issues to deal with in
designing a record abstraction.  Having taken a closer look now at the
current incarnation of the proposal, I see that it is somewhat simpler
than I had previously thought, and certainly a great deal simpler than
the original draft, although the explanation of constructor protocols
is a bit confusing.  I also didn't participate much in the discussion,
primarily because of how much of a time sink I expected it to be, so
I won't claim to have any stones to throw which might have already
been deflected in earlier discussion that I haven't the time to read
through all of.

However, that having been said, I still think that this is a great lot
of baggage to impose on Scheme, half the length of R5RS to begin with,
and I'd be very much more comfortable with clearer partitions between
components and what is optional vs required, particularly with respect
to reflection and opacity, which is still, if you'll excuse the pun,
not very clear, particularly about exactly what opacity protects
abstractions against.  It would also be comforting to have assurance
that SRFI 9 should still be supported, even if in a separate module,
which doesn't appear to be stated there.