guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: propose deprecation of generalized-vector-*


From: Daniel Llorens
Subject: Re: propose deprecation of generalized-vector-*
Date: Wed, 23 Jan 2013 00:27:57 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]