On Jan 21, 2013, at 17:11, Andy Wingo wrote: > Hi, > > Sorry for the long delay. > > Deprecating the generalized-vector functions sounds mostly sensible to > me, and the proposed semantics of array-length sound fine. Attached is > a first patch in that direction.
The changes look good to me. The patch attached applies over yours and is to document this function and a couple others in the manual. > However, before going further, some thoughts. > > Firstly, array-set! has a different interface from > generalized-vector-set!; a shame to change already sensible uses of > generalized-vector-set!. But I am OK with that. It's worse from C where one has to build a list explicitly. Maybe we should have scm_array_ref_1, scm_array_ref_2, etc. as it is done for some other functions taking rest lists. I can write a patch for that. But the argument order can't be helped. > I think it's a useful simplification, mentally, to be able to treat > generic one-dimensional indexed sequences as vectors instead of arrays. > The feedback that you get from documentation and the editor is nicer > when you don't have to deal with variable arity. Though I like removing > needless code, it seems to me that this abstraction does have some minor > benefit. I think this is a good argument for including the rank in a type system or for doing static analysis on rank, because the rank of arrays can often be determined statically. The compiler should know and this knowledge would help in debugging. But this is true for rank 2 or higher, not only for rank 1. As an interface, I prefer uniformity. My inclination whenever I use arrays is to use only the array- functions and forget about the vector- functions. > 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. > Finally, if we are doing this, then we should also deprecate the > pseudo-polymorphic uniform-vector-ref set of functions as well. If vector-set / -ref / -length works on these, they are not needed, I agree. Some of the uniform-vector functions are still needed because they handle the element type. So we would have array- / typed-array- functions for ‘views’ of any rank, and vector- / uniform-vector- functions for ‘containers’ of rank 1. Does this make sense?
0001-Array-documentation-fixes.patch
Description: Binary data
