[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: propose deprecation of generalized-vector-*
From: |
Daniel Llorens |
Subject: |
Re: propose deprecation of generalized-vector-* |
Date: |
Tue, 22 Jan 2013 19:31:29 +0100 |
On Jan 22, 2013, at 15:31, Daniel Llorens wrote:
> On Jan 21, 2013, at 17:11, Andy Wingo wrote:
>> I always wondered why vector-ref and vector-set! didn't do what
>> generalized-vector-ref and generalized-vector-set! did. I mean, they
>> are primitive generics. Might it make sense to allow vector-ref to
>> operate as generalized-vector-ref did? I really don't know, myself...
>
> I think this is fair for type polymorphism. It makes sense to let vector-
> work on uniform vectors because the implementation should be identical.
>
> It's different for arrays because even for the 1D case you need a stride and
> an indirection (and in the current Guile, also bounds).
>
> That is, I think that the main distinction is not between rank=1 and rank!=1
> objects, but between ‘container’ and ‘views’ (if this makes sense). This is
> why generalized-vector- was bad. It was an if x, do X, if y, do Y kind of
> abstraction.
To be a bit less vague…
The current implementation of scm_c_vector_ref() results in behavior such as
scheme@(guile-user)> (define (array-col A j) (make-shared-array A (lambda (i)
(list i j)) (car (array-dimensions A))))
scheme@(guile-user)> (define A #2((1 2) (3 4)))
scheme@(guile-user)> (vector? (array-row A 0))
$1 = #f
scheme@(guile-user)> (vector-ref (array-col A 0) 0)
$2 = 1
I think vector-ref should probably fail in this case, i.e. the second branch of
scm_c_vector_ref() should be gone.
On the other hand scm_c_uniform_vector_ref() goes through
scm_c_generalized_vector_ref() which does handling of offset/stride/bounds.
Instead, uniform vectors should be forced to have contiguous storage (no
offset/stride/bounds) so that scm_c_vector_ref() is able to handle them and
scheme@(guile-user) [1]> (vector-ref #f64(1 2 3) 0)
<unnamed port>:32:0: In procedure #<procedure 10293ce80 at <current input>:32:0
()>:
<unnamed port>:32:0: Wrong type argument in position 2: 0
works. This should be all right, because the only way to get non-contiguous
arrays from Scheme (iiuc) is through make-shared-array —it's natural that the
result should be handled with the array- functions.
The idea is to merge the implementations of SCM vectors and uniform vectors in
the same way that
scheme@(guile-user)> (make-array 0 2 2)
$3 = #2((0 0) (0 0))
is equivalent to
scheme@(guile-user)> (make-typed-array #t 0 2 2)
$4 = #2((0 0) (0 0))
I'm not very conversant with the macrology in vectors.h or the exact way
uniform vectors are implemented, but it seems that this should be possible.
Thoughts?
- Daniel