On Jan 22, 2013, at 21:52, Andy Wingo wrote: Hello,
> Handling stride and bounds is not a problem. The generic array handle > interface lets us do this in a straightforward way. Certainly, but in this case, a vector is just an array of rank 1. I guess I don't value that much having a specific interface just for rank 1 objects. > It was in 1.8. In 2.0 it table-driven and extensible, which isn't a bad > thing at all IMO. There is still some case jumping in evidence in scm_c_vector_ref() ... I don't think of vectors and bytevectors and uniform vectors as distinct types. Uniform vectors are an optimization where the objects in the ‘vector’ share the type tag. That's why for me it makes perfect sense to have (vector? #u8(1)) -> #t and to allow (vector-ref #u8(1) 0). And the array/typed-array interface already works like this. > 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 can rationalize this because a string is (in principle) sufficiently different from a vector, maybe because of Unicode (speaking over my head here). Not the case for numeric vectors or bytevectors, although the standards also disagree for the latter. > 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! If I understand correctly, at this point it's a matter of names —we can't use use vector?, vector-ref, etc. for this generic interface because those names are captured by the standard. > 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. I'm good with vector being shorthand for rank-1 array. Or even shorthand for type-#t rank-1 array. I was trying to carve an exclusive function for ‘vector’ that went beyond being shorthand for rank-1 array. It stands out that vector? is in fact making that distinction (vector? meaning both SCM elements *and* no stride/bounds). Maybe it shouldn't? > 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? :) Something between 1 and 2… If vector? has to be disjoint from bytevector?, presumably that's true also for f64vector?, etc. in which case we should * keep generalized-vector as it is. * restrict vector- to objects that satisfy vector?. vector? allows stride/bounds but not uniform type. This provides the disjointness. The array interface seems more logical. Everything is array? and then things are typed-array? of specific types. I see myself not using the vector interface at all. I don't know. - Daniel