array proposal

[Glenn S. Burke <GSB at MIT-ML>]

I go with Rodney's interpretation, especially in terms of the
accessors.  I've been thinking about what it will take to do this in
NIL, and what it comes down to is that it is hardly worthwhile having
the specialized accessors VREF, CHAR, and BIT if they need to handle
the general cases of those types of arrays.  (This is unfortunate
because, at least in the case of anything called a string, i would
feel bad if CHAR didn't work on it.  On the other hand, with kludging,
discriminating between exactly two types, such as STRING and EXTEND,
is easier than a dispatch, but still so gross to do inline compared
to what one would get otherwise that i wouldn't do it inline.  I
experimented with this once.)

What it comes down to is that for brevity (and interfacing to a
currently stupid compiler), i am going to provide an accessing
primitive for every simple type.  If these are not provided in
common-lisp, then they will probably have "%" as the first character
of their names and be in the chartreuse pages.  This has nothing to do
with preserving the status-quo with what NIL already uses these names
for (the simple ones, as it happens), but rather the ability to
constrain the type of reference briefly, because i believe that they
will be heavily used (certainly in the NIL internals they will be).

Of course, the NIL-colored pages will also contain things like
%string-replace, %string-translate, etc., for those who want that kind
of thing.  (These are the MOVC3 and MOVTC instructions.)