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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 22 Nov 88 15:00:25 PST
    From: Jon L White <jonl@lucid.com>

    ... I would very much like to hear you opinion on my suggestion for a
    way out of the "loophole" conflict; namely, allow the default setting of
    the of :adjustable argument to MAKE-ARRAY to be implementation-dependent.
    That way, we could maintain portability on what the :adjustable argument 
    means (i.e. NIL means "Not Adjustable").   Symbolics' users would likely 
    have no code broken, since the Symbolics default setting would be just
    be :adjustable = T.  (Does any user *ever* explicitly supply a NIL for 
    this argument?).

I don't usually supply :ADJUSTABLE NIL only because I know that's the default.
If you made the default implementation-dpeendent, I would have to supply it
a whole lot more than I do now. I recently spent a lot of time going through
some code of mine removing the need for ``:ADJUSTABLE T'' (ie, implicitly
making things ``:ADJUSTABLE NIL'' in order to incur less overhead in some
implementations to which I needed to be porting).

So I don't think what you're suggesting would be the easy solution you suggest
because any way you cut it, if you make NIL really mean not adjustable, then
you make Genera not compatible. We just don't have that bit allocated right now
and it's fairly possible that there's no room to add it. So you'd be breaking
us fairly badly under any scheme which required the distinction, regardless of
the default.

In terms of perceived breakage, your strategy might reduce the initial
perception of a problem because initially people's code would seem to run well
since most people don't have :ADJUSTABLE NIL explicitly in their code, but you'd
find that some code didn't run as efficiently when ported as it used to (and that
would be bad!) and so people would start to add :ADJUSTABLE NIL, and so the
problem would gradually become more visible.