Vectors and Arrays--briefly

[MOON at SCRC-TENEX]

In the Lisp machine (both of them), those arrays that have as few
features as vectors do are implemented as efficiently as vectors
could be.  Thus there would be no advantage to adding vectors, and
all the usual disadvantages of having more than one way of doing
something.  The important difference between Lisp computers and
Fortran computers is that on the former it costs nothing for ASET
to check at run time whether it is accessing a simple array or
a complex one, while on the latter this decision must be made at
compile time.  Hence vectors.  Since vectors add nothing to the
language on our machine, we would prefer to keep whatever is put in
for them as unobtrusive as possible in order to avoid confusing our
users with unnecessary multiple ways of doing the same thing.  Of
course, we are willing to put in functions to allow portability
to and from implementations that can't get along without vectors.

A second issue is that there are very few programs that use strings
for anything more than you can do with them in Pascal (i.e. print
them out) that would be portable to implementations that did not
permit strings with fill-pointers.  The important point here is that
it needs to be possible to create an object with a fill-pointer on
which the string-specific functions can operate.  This could be
done either by making those functions accept arrays or by making
vectors have fill-pointers.  This was discussed at the November
meeting; if my memory is operating correctly the people with
non-microcoded implementations (the only ones who care) opted for
making vectors have fill-pointers on the theory that it would be
more efficient than the alternative.  I believe it is the case that
it is really the string-specific functions we are talking about here,
not just the generic sequence functions.

To address the proposal.  1 and 2 are okay.  It is inconvenient to
enforce 3 in compiled code on the Lisp machine, since we would have
to add new instructions solely for this purpose.  It's unclear what
4 means (but presumably if it was clarified there would be no problem
in implementing it, other than the possibility that vectors might
become less efficient than arrays on the Lisp machine because of the
need to find a place in the array representation to remember that
they are vectors).  5 is okay except that the portable subset really
needs strings with fill-pointers (extensibility is also desirable,
but very much less important).  6 and 7 are okay (but see 3).

To me the important issue is that to the user of a Lisp machine,
vectors and VREF are not something he has to worry about except
under the heading of writing portable code.