New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN

[gls@Think.COM]

Issue: ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN

References:	ADJUST-ARRAY (p297)
		MAKE-ARRAY (pp286-289)
		ADJUSTABLE-ARRAY-P (p293)
		ADJUST-ARRAY-NOT-ADJUSTABLE

Category:      CLARIFICATION/CHANGE

Edit history:  02-Feb-89, Version 1 by Steele

Problem description:

The vote at the January 1989 meeting on ADJUST-ARRAY-NOT-ADJUSTABLE
left the language in an inconsistent state.  It also left
ADJUSTABLE-ARRAY-P with a fairly useless definition.

The amendment presented and approved at the January meeting stated:

(1) The results are undefined if ADJUST-ARRAY is invoked on an array
    that was created by MAKE-ARRAY without supplying :ADJUSTABLE <non-nil>.
(2) ADJUSTABLE-ARRAY-P returns true of an array created using
    :ADJUSTABLE <non-nil>.
(3) If ADJUST-ARRAY is invoked on an array for which ADJUSTABLE-ARRAY-P
    returns false, an error is signalled.

The inconsistency is that the amendment failed to strike these
parts of the original proposal:

    Clarify that the implication of [the first three paragraphs of the
    original proposal] is that saying that an array A "is adjustable"
    means that (ADJUSTABLE-ARRAY-P A) => true. ...

    Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
    predicate to determine whether ADJUST-ARRAY will reliably succeed.

The latter is in conflict with the amendment, for ADJUSTABLE-ARRAY-P
being true is no longer a guarantee that ADJUST-ARRAY can succeed.  The
best that can be said is that if ADJUSTABLE-ARRAY-P is false then
ADJUST-ARRAY is guaranteed to signal an error.  (Some implementations
might provide the extension that ADJUSTABLE-ARRAY-P being true guarantees
that ADJUST-ARRAY will win.)  Therefore the former is also nonsensical,
because it is silly to say that an array is adjustable if in fact an
adjustable array (one for which ADJUSTABLE-ARRAY-P is true) cannot be
adjusted by ADJUST-ARRAY.

Another point is that some persons have been concerned about the language
being in a state where one cannot guarantee that MAKE-ARRAY will create a
simple array.  The concerns surround the question of a portable way to
make declarations about arrays that can be exploited by implementations
on stock hardware to produce fast compiled array accesses.


Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN:TURKEY):

Rescind the amendment approved at the January 1989 meeting, cited above,
thereby restoring and approving the proposal ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY
to its state as of version 4.

Furthermore make the following change: the behavior of :ADJUSTABLE NIL,
explicitly supplied, may differ from the behavior of omitting the
:ADJUSTABLE argument in some implementations.

Implementations may be divided into three kinds, according to the behavior
of MAKE-ARRAY when given :ADJUSTABLE NIL or when :ADJUSTABLE is omitted:
(1) Always return a non-adjustable array.
(2) Always return an adjustable array.
(3) Sometimes return one kind, sometimes another.

In implementations of kind (1), a declaration that an array is simple
(using the SIMPLE-ARRAY, SIMPLE-VECTOR, SIMPLE-STRING, or SIMPLE-BIT-VECTOR
type specifier) may be taken literally: it is a guarantee that the array
in question will be, among other things, not adjustable.  The compiler in
such an implementation may rely on this declaration to produce good
compiled code.

In implementations of kinds (2) and (3), a declaration that an array
is simple is understood a little bit differently: it constitutes a
guarantee by the user that he made a good-faith effort to create a
simple array, that is, MAKE-ARRAY was given an *explicit* argument
:ADJUSTABLE NIL.  The compiler for an implementation of kind (2) will
know that its arrays are always adjustable anyway and can generate code
accordingly.  The compiler for an implementation of kind (3) may throw
up its hands, or it may use implementation-specific knowledge about
the behavior of MAKE-ARRAY to determine what code to produce; for example,
an implementation of kind (3) might provide non-adjustable strings but
not provide non-adjustable general arrays.

Therefore there is a difference between using :ADJUSTABLE NIL and omitting it;
using it entitles the user to make certain type declarations, whereas
omitting it does not entitle the user to make such type declarations.
Implementations of kind (3) might choose to interpret an explicit passing
of :ADJUSTABLE NIL as requiring a non-adjustable array, but an omission as
leaving the implementation free to make the choice; but this is only one
of many permitted interpretations.

Nevertheless, ADJUSTABLE-ARRAY-P is the sole run-time arbiter of whether
or not ADJUST-ARRAY will succeed.

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN:MONKEY):

Rescind the amendment approved at the January 1989 meeting, cited above,
thereby restoring and approving the proposal ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY
to its state as of version 4.

Implementations may be divided into three kinds, according to the behavior
of MAKE-ARRAY when given :ADJUSTABLE NIL or when :ADJUSTABLE is omitted:
(1) Always return a non-adjustable array.
(2) Always return an adjustable array.
(3) Sometimes return one kind, sometimes another.

This proposal forbids implementations of kind (3).

In implementations of kind (1), a declaration that an array is simple
(using the SIMPLE-ARRAY, SIMPLE-VECTOR, SIMPLE-STRING, or SIMPLE-BIT-VECTOR
type specifier) may be taken literally: it is a guarantee that the array
in question will be, among other things, not adjustable.  The compiler in
such an implementation may rely on this declaration to produce good
compiled code.

In implementations of kind (2), a declaration that an array
is simple is understood a little bit differently: it constitutes a
guarantee by the user that he made a good-faith effort to create a
simple array, that is, MAKE-ARRAY was not given :ADJUSTABLE <non-NIL>.
The compiler for an implementation of kind (2) will
know that its arrays are always adjustable anyway and can generate code
accordingly.

ADJUSTABLE-ARRAY-P is the sole run-time arbiter of whether
or not ADJUST-ARRAY will succeed.

Rationale:

It is silly to play a semantic game wherein one might or might not
be able to adjust an array terminologically defined to be "adjustable".

It is recognized that implementations differ on whether and when arrays
are to be adjustable, and that this state of affairs is desirable, being
motivated not only by inertia but by questions of flexibility and
efficiency as a function of hardware.  The hope is that by being just a
little more explicit about the permitted range of implementation options
we can provide a more useful semantics for ADJUSTABLE-ARRAY-P and for
array type declarations.

Current practice:

Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL (or omitted) arrays
non-adjustable, and therefore are compatible with either proposal.

Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases
and I believe it does not depend on type declarations of simple arrays,
and therefore is compatible with either proposal.

Cost to implementors:

Perhaps some implementation would have to change, but I don't know of any.

Cost to users:

None.  This is a fully compatible change from the user's standpoint.

Benefits:

Users would know what to expect; in particular, ADJUSTABLE-ARRAY-P
really would mean "can I adjust this array?"

Aesthetics:

The status quo is yukky.

Discussion:

Steele favors ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN:MONKEY, but fears that
there may be some implementation of kind (3) out there that is of kind (3)
for some important reason.  Proposal TURKEY has been provided to cover
that contingency.