Re: vectors are something else

[Daniel Hartwig]

On 12 April 2013 15:23, Daniel Llorens <address@hidden> wrote:
>
> 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.
>

Ah.  I should have read more the later part of your mail.

> 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.

I don't think this particular test is that useful, as it is too
concerned with the details of how the array indices map
to the underlying vector, rather than whether the array
indices themselves are compatible with the vector
indexing semantics.  Too restrictive IMO, you may as
well just not permit any array passed to vector
interfaces.

[Besides, you can already get at the underlying vector
using ‘shared-array-root’.]

> 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 [2] #t. But then, vector- is just
> an alias of array-.

Sure, [1] and [2] should probably be consistent.

This does not make ‘vector-’ an alias however, as the semantics
of vector indexing must still be respected.  There are two layers
of indexing, vector (simple) and array (fancy).  For some objects
the two are compatible, like in [1].  For others like address@hidden(1 2)’
they are incompatible.  This compatibility is based on the
indices themselves, not how they are calculated (e.g ‘inc!=1’ is
not relevent for compatibility).

address@hidden(a b c d) is:

 Element       a b c d
 Array index   1 2 3 4
 Vector index  0 1 2 3


There is some utility in permitting [1] where an arrays indices
are vector-compatible: array data (or a subset) can be passed to
a procedure expecting a vector without copying.

Is it worth the overhead to support this in the vector code?  I
think so, but then, haven't looked at the code :-)

Where an arrays indices are vector-incompatible, you can still
permit vector indexing of the elements by ignoring the array
indices (i.e. current ‘vector-ref’), or you can fail.  Failing
will result in less surprises.  This suggestion:

> Might as well have (vector-ref address@hidden(1 2 3 4) 1) work properly
> [by returning ‘1’ instead of ‘2’].

is not possible: the vector interface must use vector indexing
which means the first element of any object has index ‘0’.

It seems you prefer failing in the incompatible case, though I
have no strong preference either way.

For non-rank-1 arrays, the indices are clearly incompatible
though ‘array-contents’ already establishes a precedent for
the rank-1 ordering of the elements, and supporting that
case could be possible as well.


>
> 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.

Perhaps.  I assume that ‘array-map!’ etc. are more efficient for
accessing multiple elements with the startup overhead is
amortized over all the elements.

> 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.

Are those results from stable-2.0?  I do not reproduce some of
the type errors on my system, e.g.:

(bitvector-ref (make-typed-array 'b #t '(1 2)) 0) => #t


>From your original mail:
> a. the array implementation can rely on all [vector] types
> having known base=0 and inc=1.

Is that not already the case?


Regards