Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)

[Scott.Fahlman@B.GP.CS.CMU.EDU]

A few comments on KMP's triple-barrelled proposal:

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'm strongly opposed to the IMPLICIT-COPY option.  For users of
implementations that have non-adjustable arrays and that therefore do the
copy, this change would be very treacherous.  If the user is holding on to
old pre-adjustment array, things could start to fail in very mysterious and
confusing ways.  We get lots of spurious bug reports from users who screw
themselves by calling DELETE without doing the SETQ, despite all our
warnings.  This would bite fewer people, but might be harder to diagnose
when it did bite them.  And since code written on Symbolics systems, for
example, would work fine without the SETQ, it would bite people at the time
of a port to a standard architecture, often when the original author of the
code is not readily available for consultation.

I've got no strong objection to the SIGNAL-ERROR proposal, but if I were a
Symbolics-only user whose code was going to be broken by this, I might well
object.

Of the three options offered, I prefer SIGNAL-ERROR+NEW-FUNCTION, but again
I think this might bother users who are living happily under the current
system.  Also, a minor point, I think the new function should not be called
COPY-ARRAY if in fact it does adjustment.  It would be clearer to call it
FORCE-ADJUST-ARRAY or something like that.  Better still, we could just add
a :FORCE keyword arg to ADJUST-ARRAY that, if non-null, says to do the copy
in the case of receiving a non-adjustable array; the default value would be
NIL.

There's a fourth option we might want to consider: it would be like
SIGNAL-ERROR+NEW-FUNCTION, but implementations are only required to signal
the error in cases where they are unable to return an adjusted array that
is EQ to the old one.  If they can manage to adjust the array and return
it, they are allowed to do so, regardless of whether it was created with
the ADJUSTABLE keyword.  This would not break existing code in systems
where all arrays are adjustable, but would signal a nice solid
non-mysterious error when this code is ported to a different system.

-- Scott