[added srfi-164]

On 1/7/19 6:20 AM, John Cowan wrote:
> On Sun, Jan 6, 2019 at 2:10 AM Per Bothner <xxxxxx@bothner.com <mailto:xxxxxx@bothner.com>> wrote:
>
>     I think it would be helpful to allow, but not require, that
>     the uniform vector types be vectors.
>
>
> I believe that ship sailed twenty years ago.SRFI 160 is meant
> to be backward compatible with SRFI 4, which says:
> "These datatypes support operations analogous to
> the Scheme vector type, but they are distinct datatypes."

I don't think that precludes (vector? VAL) being true for a TAGvector.
Note that phrase is only in the abstract, and the specification doesn't
say anything about the homogeneous vector datatypes having to be disjoint from
other types.

Even if it did, that does not preclude tweaking the specification for srfi 160,
since requirements and goals have changed in 20 years.  The backwards compatibility
argument is weak: I would be surprised if any actual program breaks if we make
(vector? VAL) true for a TAGvector.

Note there is precedence for tweaking the Scheme type hierarchy.
SRFI 25 doesn't explicitly state that arrays and vectors are distinct, but
it does state arrays are "independent of other container data types".
However, some Scheme dialects specify that vectors are indeed a type-type of arrays.
This includes Kawa and Guile (whose arrays are SRFI 25-compatible),
and Rackets (whose arrays are not).

Now we're going to have both homogeneous and heterogeneous arrays, and we're
going to have homogeneous vectors based on SRFI 4, then it only makes sense
that homogeneous arrays be based on SRFI 4 homogeneous vectors.  If vectors
are arrays, then homogeneous vectors also need to be arrays.

I think it would be useful to have 3 concepts:

* A "uniform vector" or "homogeneous vector" is one of the types of SRFI-4 or SRFI-160.
* A "generic vector" or "heterogeneous vector" is the traditional Scheme vector:
   the result of make-vector or vector literals.
* can be either a uniform vector or a generic vector.
   A bounded range should also be a generalized vector.  The expectation is that
   TYPE-length and TYPE-ref should be efficient and O(1).
   The result of SRFI 122 storage-class-maker should be a generalized vector
   (though there is no mechanism to enforce that).

Assume a Scheme where vector is a sub-type of array, and that you want support
"homogeneous arrays". It makes sense to design "specialized arrays" (in the
SRFI 122 sense) as a transformation of a generalized vector.  In that case
array-ref needs to be able to index into generalized vector.  SRFI 122
deal with homogeneous arrays by using a "storage class" as a dispatch vector,
but if you want vector to be a sub-type of array then you need a similar
dispatch vector for generalized vector as well.  In which case it makes
sense for the vector procedures to work on generalized procedures.

I know some of you want to preserve the traditional Scheme model
of disjoint procedures for disjoint data types.  However, that model breaks
once you have a dozen or more disjoint sequence types.  Just looks at SRFI 160
with its more than 500 new procedures.  This model has failed.  If we going to add 11
new types, we can't add 50 disjoint procedures for each type.  We have to
consider the lessons of type abstraction and inheritance.  Why do we need
11 new TAGvector-any procedures when a single vector-any will do?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/