[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
- To: Barry Margolin <barmar@Think.COM>
- Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 16 Mar 89 19:02 EST
- Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: <19890316222229.3.BARMAR@OCCAM.THINK.COM>
- Line-fold: No
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.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
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.
I'd support that too. In other words, describe NSUBSTITUTE with language
similar to the description of NSUBST.