[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
- To: Scott.Fahlman@B.GP.CS.CMU.EDU
- Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 21 Nov 88 19:45:10 PST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Sun, 20 Nov 88 21:52:46 EST <8811210257.AA03776@lucid.com>
re: First, the problem statement says:
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.''
That's just a statement of fact. It doesn't give the reader any clear idea
what we think the problem is.
I for one don't think there is anything wrong with that "statement of
fact". But since Symbolics' array implementation has always been in
direct violation of this prescription, we must assume that they (and
Kent in particular) feel that adjustability must not be "an option" --
that it must be required of all arrays.
Lucid will oppose any measures to make adjustablility required of all
arrays. This is precisly the one place where a good compiler on "stock
hardware" must have some options for creating and using a subclass of
arrays competitively with "Conventional" computer lanugages [note that
"Conventional" begins with a "C"]. CL's SIMPLE-ARRAYs are that subclass;
and SIMPLE implies "not adjustable" because, regardless of whether or
not ADJUST-ARRAY returns a copy, there is no way to modify such low-
overhead arrays as per CLtL 297 [special-purpose hardware systems can
do so however, by using "invisible pointers"].
Incidentally, Lucid has a function SYS:COPY-ARRAY which does just that
-- it makes a copy preserving all the array's attributes; thus I too
would not like to see this name taken for some ersatz ADJUST-ARRAY.
Lucid implements (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR).
There was one aspect of your "fourth option" suggestion that bears some
thought. Suppose we made the default value of the :adjustable argument
to MAKE-ARRAY be implementation-dependent? That way, when adjustability
comes "for free", the user might as well have it. But if the user
***explicitly*** passes in the :adjustable argument as NIL, then
he ought to be able to check out portable code that way [i.e., find
out just where he may trying to adjust a "non-adjustable" array.]
-- JonL --