Aubrey Jaffer wrote:

> But why provide non-0-based indexes at all?  The representations for
> ranges in both SRFI-47 and SRFI-25 are ad-hoc and un-schemely.

Whatever the needs of non-0-based indexes are, we *have* a
perfectly acceptable array SRFI that is widely implemented.
The only rationales I can see for a non-compatible new SRFI are:
(1) the existing SRFI is fundamentally broken.  (Note "insufficient"
is not enough if it can be compatibly enhanced, which it can.)
(2) to provide backwards compatibility (portability) for people using
some *existing* API, such as in SLIB.  In that case, the goal is to
specify that API, and discussing how indexes should be listed is out
of place.

What I see you doing is:
(3) we can design a better library by just ignoring SRFI 25.  That
may be true, but for that to be relevant it needs to be *fundamentally*
better, not just an incremental improvement.  The new design must make
important new applications possible or non-trivially easier in a way
which would not be possibly by compatibly enhancing SRFI 25.

So which is it?  I disagree with (1) - SRFI 25 is not fundamentally
broken, and can be easily and cleanly enhanced, as I indicated in
http://srfi.schemers.org/srfi-47/mail-archive/msg00007.html
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/