Re: propose deprecation of generalized-vector-*

[Daniel Llorens]

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