> 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.
I interpret "they are distinct datatypes" as meaning not only that they (the
TAGvectors) are distinct from each other, but also that they are distinct
from Scheme vectors. I agree that it's ambiguous as written; however, all
Schemes known to me interpret them as disjoint from Scheme vectors.
Note there is precedence for tweaking the Scheme type hierarchy.
There is precedent for declaring that new types may or may not be
disjoint from old types. In addition, saying that something is a disjoint
type _tout court_ is currently an uncashable check: until we have a
complete list of R7RS-large types, we won't be able to make final
statements about disjointness.
* 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.
Words missing here?
A bounded range should also be a generalized vector. The expectation is that
TYPE-length and TYPE-ref should be efficient and O(1).
I don't agree that bounded ranges should be vectors: in particular, vectors (except
literals) are mutable, ranges are not.
The result of SRFI 122 storage-class-maker should be a generalized vector
(though there is no mechanism to enforce that).
Storage classes are explicitly implementation-dependent things in SRFI 122;
they can just be interchangeable blobs.
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.
That's why SRFI 160 has multiple libraries. My assumption is that you are likely to
want only a few types in any given program.
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?
This margin is too narrow to justify Scheme's traditional relentless monomorphism.
But I believe the correct solution is not to play with type inclusion, where reasonable
people can reasonably differ, but to provide predicate-based generic functions, which
I'll talk about when I write that SRFI. Chibi already provides a simple version of them.
--