I have already suggested this in some other post on this list, but it
hasn't been discussed yet.

The way we all seem to envision ranges (as compactly represented
vector-like data), it can be helpful to weaken the disjointness of the
range type when it comes to the built-in vector type.

My suggestion is to allow (not enforce) for an implementation not to
distinguish between a range and a vector.

For such an implementation, vector->range and range->vector would be
no-ops. Every operation on ranges works easily well on vectors and
vector operations can be applied mutatis mutandis on ranges. (*)

Thus, I propose to change "Ranges belong to a disjoint type." to
"Ranges belong to a disjoint type, except for, possibly, vectors. In
an implementation where ranges are indistinguishable from vectors
through the type predicates, procedures accepting vectors must also
accept ranges and vice versa."

By the way, it fits the idea that SRFI 196 is the vector-answer to
SRFI 116 (immutable pairs). Immutable vectors (conceptionally) are
nothing but ranges.

Marc

--

(*) I know that ranges can only be viewed as read-only vectors, but so
are vector literals. Conceptually, the vector API therefore already
knows about immutable vectors.