[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
- To: Patrick Dussud <firstname.lastname@example.org>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Richard P. Gabriel <email@example.com>, masinter.pa@Xerox.COM, gls@Think.COM, Jon L White <firstname.lastname@example.org>, Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 9 Mar 89 15:23 EST
- Cc: email@example.com
- In-reply-to: <8901271629.AA21144@challenger>, <19890128032256.5.MOON@EUPHRATES.SCRC.Symbolics.COM>, <890130110045.5.KMP@BOBOLINK.SCRC.Symbolics.COM>, <8901301613.AA03528@challenger>, <19890130164936.0.MOON@EUPHRATES.SCRC.Symbolics.COM>, <8901301750.AA03759@challenger>, <890130142828.2.KMP@BOBOLINK.SCRC.Symbolics.COM>, <8901301933.AA03928@challenger>, <8901302154.AA04106@challenger>, <890130173552.5.KMP@BOBOLINK.SCRC.Symbolics.COM>, <890130-144905-6017@Xerox>, <19890131045316.7.MOON@EUPHRATES.SCRC.Symbolics.COM>, <8902020519.AA03069@sauron.think.com>, <8902061636.AA27928@verdi.think.com>, <8902072038.AA23870@bhopal>, <890214-155752-10883@Xerox>, <890215094330.2.KMP@BOBOLINK.SCRC.Symbolics.COM>, <8902151603.AA03972@challenger>, <890215-082818-12355@Xerox>, <firstname.lastname@example.org>, <890215-111623-12827@Xerox>, <890215142157.9.KMP@BOBOLINK.SCRC.Symbolics.COM>, <8902281036.AA08748@bhopal>, <8902281913.AA03555@verdi.think.com>
- Line-fold: No
After re-reading all 24 of these messages, I believe that version 7,
mailed by KMP on Feb 15, adequately captures the result of the discussion.
I would certainly like to vote yes on it at the end of this month
and then never hear about it again. There are a couple of small
changes that are worth making; see below.
I believe it captures what RPG was looking for, but I'd like to hear
confirmation of that from Dick.
Part of this issue is JonL's concern that the type SIMPLE-ARRAY is not
adequately specified. I believe that the logical implications of the
version 7 proposal adequately specify the meaning of SIMPLE-ARRAY, and
that this is not a change from CLtL, only a clarification. Evidently
there are other ways to read the sentence at the bottom of p.28, but the
way I read it, it says that simple arrays are ones that an
implementation can handle in a more efficient manner, and that arrays
that don't use certain features are simple, but does not say that no
other arrays can be simple. Do we need to add any language to the
version 7 proposal to clarify this? Adding JonL's suggested
"This proposal does not alter the definition of SIMPLE-ARRAY in any way."
would be fine with me. By the way I feel that I completely understand
the stock hardware implementors' concern with simple arrays and that
this proposal does not harm that concern in any fashion.
The front of the version 7 writeup says Category: CLARIFICATION/CHANGE,
but I believe it is only a clarification. The only part that might be
counted as a change is the replacement of CLtL's "It is not permitted to
call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
option" (p.297) with "ADJUST-ARRAY should signal an error if
ADJUSTABLE-ARRAY-P of its first argument is false." I think it's not a
change, because it doesn't affect any conforming programs, it only
affects implementations. As the proposal says
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Thus I would like to see the category at the front changed to plain