Re: `Vectors versus Arrays', and the original compromise

[JonL at PARC-MAXC]

During the Nov 1981 CommonLisp meeting, the LispM folks (Symbolics, and 
RG, and RMS) were adamantly against having any datatype for "chunked" 
data other than arrays.  I thought, however, that some sort of compromise was
reached shortly afterwards, at least with the Symbolics folks, whereby VECTORs
and STRINGs would exist in CL pretty much the way they do in other lisps not
specifically intended for special purpose computers (e.g., StandardLisp, PSL,
Lisp/370, VAX/NIL etc).

It was admitted that the Lispm crowd could emulate these datatypes by some
trivial variations on their existing array mechanisms -- all that would be forced
on the Lispm crowd is some kind of type-integrity for vectors and strings, and
all that would be forced on the implementors of the other CLs would be the 
minimal amount for these two "primitive" datatypes.  Portable code ought to use
CHAR or equivalent rather than AREF on strings, but that wouldn't be required,
since all the generic operations would still work for vectors and strings.

So the questions to be asked are:
 1) How well have Lisps without fancy array facilities served their
    user community?  How well have they served the implementors
    of that lisp?   Franz and PDP10 MacLisp have only primitive
    array facilities, and most of the other mentioned lisps have nothing
    other than vectors and strings (and possibly bit vectors).   
 2) How much is the cost of requiring full-generality arrays to be
    part of the white pages?  For example, can it be assured that all
    memory management for them will be written in portable CL, and
    thus shared by all implementations?  How many different compilers
    will have to solve the "optimization" questions before the implementation
    dependent upon that compiler will run in real time?
 3) Could CL thrive with all the fancy stuff of arrays (leaders, fill pointers,
    and even multiple-dimensioning) in the yellow pages?  Could a CL
    system be reasonably built up from only the VECTOR- and STRING-
    specific operations (along with a primitive object-oriented thing, which for
    lack of a better name I'll call EXTENDs, as  in the NIL design)?  As one
    data point, I'll mention that VAX/NIL was so built, and clever things
    like Flavors were indeed built over the primitives provided.
I'd think that the carefully considered opinions of those doing implementations
on "stock" hardware should prevail, since the extra work engendered for the
special-purpose hardware folks has got to be truly trivial.

It turns out that I've moved from the "stock" camp into the "special-purpose"
camp, and thus in one sense favor the current LispM approach to index-
accessible data (one big uniform data frob, the ARRAY).   But this may
turn out to be relatively unimportant -- in talking with several sophisticated
Interlisp users, it seems that the more important issues for them are the ability 
to have arrays with user-tailorable accessing methods (I may have to remind 
you all that Interlisp doesn't even have multi-dimension arrays!), and the ability
to extend certain generic operators, like PLUS, to arrays (again, the reminder that
Interlisp currently has no standard for object-oriented programming, or for
procedural attachment).