Re: propose deprecation of generalized-vector-*

[Andy Wingo]

Hi Daniel,

Thanks for thinking about this.

On Tue 22 Jan 2013 19:31, Daniel Llorens <address@hidden> writes:

>> 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).

Handling stride and bounds is not a problem.  The generic array handle
interface lets us do this in a straightforward way.

>> 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.

It was in 1.8.  In 2.0 it table-driven and extensible, which isn't a bad
thing at all IMO.

> 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

    scheme@(guile-user)> (vector? "foo")
    $1 = #f
    scheme@(guile-user)> (generalized-vector? "foo")
    $2 = #t
    scheme@(guile-user)> (vector-ref "foo" 1)
    <unnamed port>:3:0: Wrong type argument in position 2: 1
    scheme@(guile-user)> (generalized-vector-ref "foo" 1)
    $3 = #\o

The error message is incorrect, unfortunately... anyway.  I think this
highlights the reason why we can't make vector-ref generic: vector? and
string? should be disjoint predicates.  (Or should they?  Scheme has
real problems with polymorphism.  I don't know and am interested in
arguments.)

> I think vector-ref should probably fail in this case, i.e. the second
> branch of scm_c_vector_ref() should be gone.

My instinct would be to redefine vector as an interface of sorts:
vector-indexable.  Generic vector.  generalized-vector -- oh wait we're
back to the beginning!

> uniform vectors should be forced to have contiguous storage (no
> offset/stride/bounds) so that scm_c_vector_ref() is able to handle
> them

Not sure this is really what should happen.  The generalized array
interface from generalized-arrays can deal with this quite well, with no
need for a restriction.

> Thoughts?

I think the string case is vexing, and we really need to go back to
fundamentals.

What is a vector?

Possible answers:

  1. A vector is something that answers #t to vector?, which contains
  some number of storage slots accessible in a mostly-O(1) way, the
  number of slots is given by vector-length, and the slots can be
  accessed with vector-ref and vector-set!.

  2. A vector is a specific kind of object, implementing the interface
  described above, and disjoint from all other kinds of objects.

  3. A vector is a specific kind of object, as before, disjoint from all
  other kinds of objects defined in the R5RS.

  4. A vector is a specific kind of object, as before, disjoint from all
  other kinds of objects defined in the R6RS.

(1) defines vectors as an interface.

(2) defines vectors as a specific data structure.

(3) admits to a number of distinct types that may be vectors, of which
    one kind is defined by the R5RS.

(4) is like (3), but it precludes bytevectors from being vectors.

What do you think a vector is? :)

Andy
-- 
http://wingolog.org/