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.