guile-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]