Re: Vectors and Arrays

[Scott E. Fahlman <FAHLMAN at CMU-20C>]

This is basically a re-send of a message I sent yesterday, attempting to
clarify the Vector/Array proposal.  Either I or the mailer seems to
have messed up, so I'm trying again.  If you did get the earlier
message, I apologize for the redundancy.

To clarify the proposal: The Common Lisp spec would require that VREF
and VSET work for all vectors.  If they also work for other kinds of
arrays in Zetalisp (i.e. they just translate into AREF and ASET), that
would be OK -- another way in which Zetalisp is a superset.  As with the
business about extensibility, it would be nice to have a compatibility
mode in which VREF would complain about non-vector args, but this is not
essential.  Note also that Zetalisp users could continue to write all
their code using AREF/ASET instead of VREF/VSET; if they port this code
to a "Fortran machine" it would still work, but would not be optimally
fast.

The whole aim of the proposal is to allow Zetalisp to continue to build
arrays their way, while not imposing inefficiency on non-microcoded
implementations.  So we would definitely provide accessing and modifying
primitives for getting at fill-pointers and the like.  Legal Common Lisp
code would not get at such things by looking in slot 27 of the array
header vector, or whatever.

I would not be violently opposed to requiring all vectors (including
strings) to have a fill pointer.  This would cost one extra word per
vector, but the total overhead would be small.  It would not really cost
extra time per access, since we would just bounds-check against the
fill-pointer instead of the allocated length.  If a compiler wants to
provide (as an option, not the default) a maximum-speed vector access
without bounds checking, it could still do so, and would run roughly the
same set of risks.  (Probably this is unwise in any event.)  So the cost
of fill pointers is really not so bad.  The reason we left them out was
because it seemed that providing a fill-pointer in a non-growable vector
was not a useful or clean thing to do.  And allowing vectors to grow
really is a significant added expense without forwarding pointers in the
hardware.

Do the Zetalisp folks really want fill pointers in non-growable strings,
or would it be better to go with mostly simple strings, with character
arrays around for when you want an elastic editor buffer or something?

-- Scott
   --------