[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `Vectors versus Arrays', and the original compromise
- To: Dick Gabriel <RPG at SU-AI>, Moon@mit-mc
- Subject: Re: `Vectors versus Arrays', and the original compromise
- From: JonL at PARC-MAXC
- Date: Tue, 14 Sep 1982 22:23:00 -0000
- Cc: common-lisp at SU-AI
- In-reply-to: RPG's message of 13 Sep 1982 1133-PDT
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