vectors are something else

[Daniel Llorens]

After the array-map patches, I've gone through the vector/array implementation 
and there's some stuff I'd like to fix. In stable-2.0 today:

(define a (make-typed-array ''f64 0 '(1 2))
a
=> address@hidden(0.0 0.0)

so far so good.

(uniform-vector? a)
=> #t

(f64vector-ref? a)
=> #t

so far so good.

(uniform-vector-ref a 0)
=> 0.0

This is a bug, since the valid indices are 1 and 2. This bug is in 
scm_c_generalized_vector_ref (and elsewhere):

pos = h.base + h.dims[0].lbnd + idx * h.dims[0].inc

this should be (to fix the bug: it shouldn't be written like this, but let's 
leave that aside for now)

pos = h.base + (idx - h.dims[0].lnbd) * h.dims[0].inc

Cf.

(vector-ref address@hidden(1 2 3 4) 1)
=> 2 (wrong)

but

(array-ref address@hidden(1 2 3 4) 1)
=> 1 (right)

I have patches for the above; however, the problems go well beyond.

(bitvector? (make-typed-array 'b #t 2))) => #t
(bitvector? (make-typed-array 'b #t '(1 2))) => #f
(bitvector-ref (make-typed-array 'b #t '(1 2))) => type error (consistent with 
#f)

(bytevector? (make-typed-array 's8 0 2))) => #t
(bytevector? (make-typed-array 's8 0 '(1 2))) => #f
(bytevector-ref (make-typed-array 's8 0 '(1 2))) => type error (consistent with 
#f)

(s8vector? (make-typed-array 's8 0 2))) => #t
(s8vector? (make-typed-array 's8 0 '(1 2))) => #t
(s8vector-ref (make-typed-array 's8 0 '(1 2))) => type error (inconsistent with 
#t)

(uniform-vector? (make-typed-array 's8 0 2))) => #t
(uniform-vector? (make-typed-array 's8 0 '(1 2))) => #t
(uniform-vector-ref (make-typed-array 's8 0 '(1 2))) => 0 (consistent with #t, 
but wrong)

(vector? (make-typed-array #t 0 2))) => #t
(vector? (make-typed-array #t 0 '(1 2))) => #f
(vector-ref (make-typed-array #t 0 '(1 2)) 0) => 0 (inconsistent with #f *and* 
wrong)

This is what I would like to do:

Force, and assume, inc and base to be 1 & 0 for uniform-vector / 
[srfi4type]vector / vector. That is, make all of the above behave as bitvector 
and bytevector. The advantanges are

a. the array implementation can rely on all these types having known base=0 and 
inc=1.
b. consistency.

Some programs may break, but they can't have relied on the behavior above 
without being broken already. Nobody has reported these bugs for a long time 
and the tests don't see them, I say we're good to go. 

Thoughts?

        Daniel

--

PS Some other, clearly worse, options:

1. Fix the bug above in uniform-vector-ref, etc. by having all the 
uniform-vector functions be aliases for array-ref. For consistency, do the same 
for bitvector- and bytevector- and srfi4vector- . Then all those functions pay 
the abstraction cost of using array- (which is not so much the rank as the 
type). It's also a fair amount of work. For example, the printer for uniform 
vectors depends on the first valid index being 0, so just fixing the buggy line 
above breaks the printer. The documentation does say that uniform-vectors are 
indexed from 0...

2. Fix the bug above in uniform-vector-ref, etc. by allowing inc!=1 and base!=0 
for non-array objects. This will push some of the array functionality into 
bitvector, bytevector, etc (where inc=1 and base=0 are hardcoded) and generally 
complicate the code. Ditto for fixes required in other places.

3. Do 0, 1, or 2 differently for each of the vector types, e.g. Having 
srfi4vector- and uniform-vector- behave like bytevector-, but vector- behave 
like array-. Besides not making much sense, it would complicate the 
implementation of arrays (by which I mean, it wouldn't allow simplification 
that is sorely needed).