Re: strings, symbols, vectors, etc.

[Michael Livshin]

Dirk Herrmann <address@hidden> writes:

> > * regular vectors.
> > 
> >   I think they are properly uniform vectors -- they are
> >   randomly-addressable sequences.  ditto for weak vectors.
> 
> OK, but as long as GOOPS isn't integrated, this means to have to dispatch
> on everything, which is part of what makes the current code in unif.[ch]
> amd ramap.[ch] so complicated.

no argument here.

> > * bit vectors.
> > 
> >   bit vectors certainly are randomly-addressable sequences, and in
> >   light of this it seems (to me at least) natural to consider them a
> >   kind of uniform vectors.
> 
> Well, OK.  However, I still think that the _layout_ of bit vectors may
> differ from the layout of all other uniform vectors.  In other words, it
> would be wise to use SCM_BITVECTOR_LENGTH instead of
> SCM_UVECTOR_LENGTH.

hmmm...  I'd think that bitvectors should be represented differently
from other uvectors because then the representation of other uvectors
can be optimized with the assumption that the elements are at least
byte-aligned.  lessee, by that logic there can be 3 different
representations: for at-least-bit-, at-least-byte- and
at-least-word-aligned uniform vectors.  I'm probably being
over the top now. ;)

but in general, there's certainly no point in making the low-level
macros generic in any way that can reasonably constrain the
implementation.  if that's what you mean.

> For example, I'd favor a layout of uniform vectors where the base element
> size was easily extractable.  When for example using double cells for the 
> uniform vectors, it would be better to store the vector's length in a full
> word of the double cell (thus allowing for longer vectors), and using the
> unused bits of the type word to store the sizeof the vector's elements,
> or maybe just the uniform vector subtype information (as it is done for
> smobs and ports).

when I was toying with this stuff a year or so ago, the thinking went
like this:

word0: tag + flags + <element-size>
word1: length
word2: data
word3: <contained-type>

where <contained-type> is something that describes the type of
elements and also whether the vector is mutable/direct etc.

bit-aligned vectors could use a similar representation with a
different tag (or flags).  ditto for word-aligned.

> This, however, does not work well with the bitvectors,
> since there is no usable sizeof(bit) in C.

what do you mean?

> Yes, a byte vector type exists, but only for signed chars.  The string
> type is (mis)used for the representation of uniform vectors of unsigned
> chars.

IMHO there's nothing parenthetical about it. ;)

-- 
Don't trust these UNIX people.  They are all demons.  They kill their
parents and fork children.  I don't know how they could do this with
their balls cut off but they manage.                        -- anonymous