[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


[Removed X3J13; added cl-cleanup]

> Date: Tue, 20 Jun 89 22:35:42 PDT
> From: Jon L White <jonl@lucid.com>
> Throughout all the thousands and thousands of lines of commentary on this 
> topic, I've yet to see one that justified breaking the portability of 

I'm not convinced the breakage is really all that severe.  By analogy,
we're now saying that at least a certain subset of INTEGERs are
guaranteed to be FIXNUMs, but an implementation may very well have
other numbers that are FIXNUMs too.  People still seem to think that
FIXNUM declarations are useful and can be used portably.  This
proposal is just saying that at least a certain subset of ARRAYs are
guaranteed to be SIMPLE-ARRAYs, but that an implementation is
permitted to have other things be SIMPLE-ARRAYs too.

The only thing that might be broken is if somebody is depending on an
array being of type (AND ARRAY (NOT SIMPLE-ARRAY)).  But my
understanding is that, in current practice, this usage is already not
portable.  I think that's justification enough for this aspect of the
proposal, although of course it has to be weighed against the
advantages of tightening the definition of SIMPLE-ARRAY.

> [In fact, I 
> supported Kent's long-lost proposal that called for ADJUST-ARRAY to work
> like DELETE, returning a copy when it couldn't alter the array "in
> place".  I had hoped that the :adjustable option to MAKE-ARRAY would
> thus acquire the meaning "adjustable in place".]

That is pretty much what the current proposal says for the behavior of
ADJUST-ARRAY, especially if the change I suggested (to disallow bashing
of the original array unless the return value is EQ to it) is adopted.

Incidentally, this also points out our motivation for wanting
ADJUSTABLE-ARRAY-P removed entirely.  There isn't a corresponding
predicate to test whether DELETE would return a copy or alter the
array "in place", and people have been getting along without it just