Very well. I'm now on Tangerine, but once I've posted a version of that, I'll go back and do a comprehensive pass over the Rationales in Red, trying to reorganize them to serve the purposes of the Report. I will strenuously avoid changing any meanings, or removing anything (except, e.g., comparisons to R4RS and the like). I'll also be very sensitive to the wishes of this group, and of the original SRFI authors.Who has signoff on changing text (as opposed to removing it)? The original SRFI author? This list? Or...?
Since you are preparing this book and you are in conformity with the SRFI license, you do. Of course we have the right to complain (as does the original author) if you change the meaning.
Yes, that's my problem with “object”. Unfortunately, it has a lot of meanings in the Lisp world and elsewhere (remember Alan Kay's comment on whether C++ is object-oriented). However, I take your point, and regard this issue as dead."Object" is old in the Lisp world, although in Lisp 1.5 it apparently meant "symbol". Googling for ["Lisp" "object" -CLOS] returns lots of uses of "object" meaning "value" for both CL and Elisp.
I think I'll put a sentence or two in the Introduction saying this, and pointing out that an implementation can be Red-compliant [sic] without implementing these features. Thus portable programs should eschew them.You can and should say that about optional features. But implementers must implement deprecated features, and users can certainly use them as long as they realize the features are not future-proof (nor is anything, really).
That makes sense.
-- vincent