Re: vectors are something else

[Daniel Llorens]

On Apr 12, 2013, at 01:53, Daniel Hartwig wrote:

> On 11 April 2013 07:07, Daniel Llorens <address@hidden> wrote:
>> 
>> 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):
> 
> For a vector, the valid indices are as specified by r5rs:
> 
> The _valid indexes_ of a vector are the exact non-negative
> integers less than the length of the vector.  The first element in a
> vector is indexed by zero, and the last element is indexed by one less
> than the length of the vector.
> 
> which applies even when accessing arrays as vectors.  Offset indexing
> is a feature of the array interface only.

Right. I want [0]

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

to fail with a type error, which is consistent with r5rs.

However my proposal is also to produce the same type error when the argument is 
a rank-1 array with base!=0 or inc!=1. These may be indexed from 0, but can 
only be produced by using the array interface, and use the array implementation 
internally. E.g. now you can do [1]

(vector-ref (make-shared-array #(1 2 3 4) (lambda (i) (list (* 2 i))) 2) 0) => 
1 

which is 'correct' (and that object cannot be told apart from a plain vector 
using r5rs functions)

even though [2]

(vector? (make-shared-array #(1 2 3 4) (lambda (i) (list (* 2 i))) 2)) => #f

Forbidding [1] will break some programs. Yesterday it broke a program of mine 
where I was using vector-ref on an array which was a row in a rank 2 array. I 
think we have license to do this anyway because of [2] and because that's how 
the typed vectors work too (bitvector-, bytevector-).

The other option is to make [1] #t. But then, vector- is just an alias of 
array-. Might as well have (vector-ref address@hidden(1 2 3 4) 1) work properly.

This discussion came up months ago when the generalized-vector interface was 
deprecated. At that time, Andy Wingo wanted to keep [1] working or at least I 
that's what I understood. My motivation try this again now is to simplify the 
implementation of arrays.

Currently there is a chain of 4 function calls for a single use of array-ref 
(and I may have missed some). This is unacceptable. Also the vector and 
uniform-vector functions are all branched on whether the argument is internally 
a 'vector' or 'srfi4-vector' or not, which is the source of the inconsistencies 
I reported in the previous post. 

I'll send a patchset later today with at least the interface changes.

Regards,

        Daniel