On 2020-09-01 21:45 +0200, Marc Nieper-Wißkirchen wrote:
> I don't understand this argument. Some vectors are mutable, other
> vectors aren't mutable.
>
> This is irrelevant for any observable behavior of a program. The
> actual question is a different one: Do we want to enable writing
> polymorphic code that distinguishes between vectors and ranges?*

I'm understanding your point as being that whether ranges are
implemented as mutable objects is irrelevant to their behavior as
ranges.  Maybe I've completely misunderstood, though.

Is there a significant advantage to allowing ranges and vectors to
be the same type, potentially?  It's easy enough to implement ranges
as vectors, but I don't see any reason to do that.  Or is the more
radical idea of implementing vectors compactly, as ranges, that you
had in mind?

On the topic of mutability: since ranges are now an abstract type, and
no longer a (bound, length, indexer) triple, mutable ranges are, I
think, a plausible extension (hypothetically speaking--I'm not
suggesting a further addition to this SRFI).  Nothing precludes such
an extension other than the statement "ranges are immutable
collections" in the Abstract.  Thus, I prefer "soft immutability" here
(no destructive procedures specified, but mutation not explicitly
disallowed).

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"I started out as a BASIC programmer.  Some people would say that I'm
permanently damaged.  Some people are undoubtedly right." --Larry Wall