[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
- To: firstname.lastname@example.org, email@example.com
- Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Wed, 15 Feb 89 17:41:50 GMT
- In-reply-to: firstname.lastname@example.org's message of 14 Feb 89 15:56 PST
> 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.'' This is inconsistent with
Well, the other sections don't say anything explicitly, and this one
does; so why doesn't this one take precedence?
> Specifying the points left unspecified (requiring all simple arrays to be
> non-adjustable and all adjustable arrays to be non-simple) would require
> large changes to some implementations and would be of little benefit to
> users, merely making one kind of nonconforming program fail in all
> implementations instead of failing only in some implementations.
This is kind of strange. I think it's a good thing when nonconforming
programs fail everywhere, and not something we should just dismiss.
We should allow such differences only when there are good reasons to
> need to know that certain arrays are simple, so they can put in
> declarations and get higher performance, but users have no need to be
> able to create arrays that are definitely non-simple (for lower
> performance) or definitely non-adjustable (to cause errors).
Surely the performance of an array with certain characteristics
is the same whether or not we say it's simple. So creating arrays
that are definitely non-simple is not a request for lower performance.
> Pitman wishes some of the other proposals were economically feasible to
> pursue but reluctantly agrees that maintaining (and clearly documenting)
> the status quo is probably the most reasonable avenue left to us.