Arrays and Vectors

[Kent M. Pitman <KMP at MIT-MC>]

I am in agreement with much of the "RPG memorial" proposal. A few comments
on the few parts that left me feeling uneasy...
-----
    Date: Thursday, 23 September 1982  00:38-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>
    Re:   Arrays and vectors (again)

    ... If an implementation does not support vectors, the :VECTOR keyword is
    ignored except that the error is still signalled on inconsistent cases;
    The additional restrictions on vectors are not enforced.  MAKE-VECTOR is
    treated just like the equivalent make-array.  VECTORP is true of every
    1-D array, STRINGP of every CHAR-SEQUENCE, and BIT-VECTOR of every
    BIT-SEQUENCE.
-----
If an implementation DOES support vectors, does VECTORP return true for 
all 1-D arrays? If not, I think you have this backwards. If an implementation
doesn't support vectors, VECTORP, STRINGP, and BIT-VECTOR should always
return NIL... I think this answers DLW's point about strings wanting to not
be vectors. In his system, vectors will not exist, so he may write:
 (COND ((VECTORP foo) (PRIMITIVE-THAT-DOESNT-WORK-ON-REAL-VECTORS foo))
       ...)
and though erroneous, it would run in his implementation. He wouldn't find
out that it that primitive wouldn't work on real vectors until he ported his
code to other systems. Further, he can't write
 (COND ((VECTORP foo) ...code for sites with vectors...)
       (T ...code for things that wouldnt' be vectors at other sites...))
because the things that wouldn't be vectors at other sites are still vectors
on his machine which doesn't claim to support vectors.

The right thing for sites that don't have vectors is to make them punt and
always use the fully generic operators. You'll never get to code that calls
hairy generic stuff if you have VECTORP lie and say everything is simple!
You want it to lie and say everything is not.
-----
    CHAR-SEQUENCEs, including strings, self-eval; all other arrays cause an
    error when passed to EVAL...
-----
In thinking about this, I'm relatively convinced that the exact set of things
which want to self-eval are those things which are intended to be typed in.
The reason is that other things just don't tend to wind up in evaluable
positions. I can't imagine how I could ever get (PRINT <hairy-string>)
very easily and I'm inclined to think it's an error. It's easy to see how
(PRINT <var-holding-hairy-string>) can happen, but that's not going to
cause the hairy-string to be EVAL'd, so it doesn't matter. Seems like it'd be
worth the error checking to make only strings self-eval. 
-----
    EQUAL descends into CHAR-SEQUENCEs, but not into any other arrays.
-----
I would argue that this also follows from the fact that the contents of this
kind of array are always visible. In this sense, this satisfies the novice's
heuristic about EQUAL that says if two things print the same, they are 
probably EQUAL. I suspect that the same reasoning says that BIT-SEQUENCEs
should also be descended by EQUAL. It should probably be made clear that 
EQUAL descends only the main data area of the arrays it descends and not the
array leader. Indeed, I assume that a string (having no array leader) can be
equal to a CHARACTER-SEQUENCE which has one if the main data areas are the
same? In that case, does the fill-pointer looked at in the complex case?
I assume so. That should also be made explicit in the documentation.
-----
    EQUALP descends into arrays of all kinds, comparing
    the corresponding elements with EQUALP.  EQUALP is false if the array
    dimensions are not the same, but it is not sensitive to the element-type
    of the array, whether it is a vector, etc.  In comparing the dimensions of
    vectors, EQUALP uses the length from 0 to the fill pointer; it does not
    look at any elements beyond the fill pointer.
-----
Again, I take it that it doesn't descend array leaders?