On 12 April 2013 15:23, Daniel Llorens <daniel.llor...@bluewin.ch> wrote: > > Right. I want [0] > > (vector-ref #@1(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 ‘#1@1(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). #1@1(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 #@1(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
