[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
- To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
- Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
- From: Barry Margolin <barmar@Think.COM>
- Date: Thu, 16 Mar 89 17:22 EST
- Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
- In-reply-to: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
I think I remember my reason (it's been a month since I wrote the
amendment). I removed NSUBST because CLtL was already very specific
about what it does. CLtL's description of NSUBSTITUTE isn't very
specific; removing it from the proposal would just leave it implicitly
vague instead of making it explicitly vague, and I'd prefer to be
explicit.
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
barmar