Re: strings, symbols, vectors, etc.

[Dirk Herrmann]

On 28 Sep 2000, Michael Livshin wrote:

> wasn't scm_vector_set_length_x disabled or something?  it's certainly
> not available from Scheme.  I think it's good, and we shouldn't
> introduce more things like that unless absolutely necessary.

It's still available from C, but, as I said, at least some of the places
where it is currently used, could (should) be changed.

> > * The code in ramap.[ch] and unif.[ch] merges a couple of concepts that
> >   might better be handled separately.  For example, the attempt to treat
> >   bitvectors in common with the other uniform vector types complicates the
> >   code a lot.  Further, strings, vectors and weak vectors are also handled
> >   in many operations together with the uniform vector types.
> > 
> >   It would mean a great simplification to factor out the handling of
> >   bitvectors from unif.c, and also not to handle strings as vectors any
> >   more.  Maybe for those functions that explicitly use uniform vectors it
> >   would also make sense to drop the support for vectors and weak
> >   vectors.
> 
> this is an interesting issue.
> 
> * 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.

> * 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.
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).  This, however, does not work well with the bitvectors,
since there is no usable sizeof(bit) in C.

In SRFI-4 (Homogeneous numeric vector datatypes) there is also no bit
vector type discussed, which probably has its reasons.

> * strings (and symbols).
> 
>   strings are not necessarily randomly-addressable sequences.  if/when
>   the plans for internatiolization of Guile string handling are
>   carried through, Guile strings will use a multibyte encoding, so
>   vector-like set/ref operations won't be very practical on them.  so
>   I think they should *not* be handled they way uniform vectors are.
>   there is also no need for that, as a separate byte vector type
>   exists (does it?).

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.

Best regards
Dirk