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

ADJUST-ARRAY-NOT-ADJUSTABLE



The complexity of this discussion about adjust-array makes me wonder 
if this function isn't striving for too much generality.   Virtually all 
usages I've seen or heard of are really for adjust-array-size.  KMP's 
proposal sounds like he's trying to avoid simply makeing a new array and 
copying (after some fashion) the old into the new.  Maybe it's a simpler 
language design not to try to cover every possible base, but to provide the 
primitives that permit end-users to "roll their own".  In line with 
your remarks:

    Having ADJUST-ARRAY sometimes adjust the original array and sometimes
    make a copy is dangerous.  I suppose it's no more dangerous than
    NREVERSE and SORT, but we know that programmers from all walks of life
    consistently have trouble using NREVERSE and SORT correctly.  I'd like
    to see some thought given to improving the proposal to make it less
    dangerous.

How about the following simplification for adjust-array:
  (1) a new function shall be added which will copy parts of the contents
      of one array into another; MacLisp's FILLARRAY is a base-level start
      for such a function, but one would like something for multi-dimensional 
      arrays that is more meaningful than simple linear, row-wise fill.
  (2) adjust array will only "mess" with the size (or dimensions) and with
      the displacement (i.e., to a new target array, or new index-offset).
      Fill-pointers can already be modified with setf.  Getting new contents
      into a displaced, "adjusted" array can be done by first calling the 
      function ARRAY-DISPLACED-P (as specified in GLS's "clarifications" of
      6-Dec-85) and then using the function called for in (1) to copy parts
      of the original displaced-to array into the newly-displaced one.

-- JonL --