s/vector/vec Panagiotis Vossos 06 May 2003 11:21 UTC

I came across this srfi a couple of days ago, which is great since it
means I don't have to waste any more time with my own (very small)
srfi-1 like vector library.  Big thanks to Taylor and all the others
that have contributed so far.

It would be _great_ IMHO, if this library was not restricted to r5rs
vectors, but also applied to all objects that have (r5rs)vector-like
properties, i.e. integer indexed objects starting at 0 with O(1)
retrieval & update.  The reason is that we /already/ have srfi-4 with
its {f32,f64,...}vectors that offer exactly the same interface, and it
will be a nuisance if someone has to rewrite srfi-34 operations for
these types.

So how can it be done?  One way is to use, say, vec-ref, vec-set!,
vec-length, vec? generic functions that accept any (r5rs)vector-like
object and have different constructors for each one of them (exactly
as it is now -- make-vector, make-f32vector etc).  If a srfi-34
function doesn't (directly or indirectly) construct a new vector it
can operate solely in terms of vec-ref etc. without caring about the
specific type of vector it is applied to.  If, OTOH, a srfi-34
function _does_ construct a vector, or calls another function that
constructs one, its definition can be changed from:

(foo v arg1 arg2 ...), to:

(foo konstr) -> (lambda (v arg1 arg2 ...)),

where konstr is a constructor with the same interface with
make-vector, i.e. make-f32vector, make-bazvector etc.

This of course raises the question of how these generic vec-foo
operations are defined.  This could be left unspecified.  A scheme
system that supports srfi-4 for example could implement it very simply
as:

(define (vec-length x)
  (cond
    ((vector? x) (vector-length x))
    ((f32vector? x) (f32vector-length x))
    (... ...)
    (else (error "VEC-LENGTH: no applicable method."))))

A system supports some kind of clos-like system can even let the user
define his own methods and extend the system.

I came across this when, after implementing an interface to fortran
vectors, I realized that I don't want to maintain two different
versions of my vector library; one for r5rs and one for foreign
vectors.  I changed my library accordingly and I find it quite
convenient.

I am pretty sure that I either have obviously overlooked something
crucial or there is an easier solution to this.  In both cases, I
would be glad if someone responds and corrects me.

regards,
panagiotis.