|     * To: srfi-47@srfi.schemers.org
 |     * Subject: consider exclusive index ranges
 |     * From: Ray Blaak <xxxxxx@ensemble-systems.com>
 |     * Date: Thu, 13 Nov 2003 10:06:41 -0800
 |     * Delivered-to: srfi-47@srfi.schemers.org
 |
 | Title: consider exclusive index ranges
 |
 | > One more comment: Why specify bounds as two-element lists rather than as
 | > pairs? It seems a bit strange to allocate two cons cells when the data
 | > is known to always contain exactly two values. Is there some reason why
 | >     (make-array '#(foo) '(0 2) '(0 2))
 | > is preferable to
 | >     (make-array '#(foo) '(0 . 2) '(0 . 2))
 |
 | Allow both. Typing (0 . 2) all the time is more tedious. (0 2) is
 | just as easy to read (easier in fact, I think) and easier for the
 | programmer to write.

Yes; and in a proportional font, ( 0 . 2 ) starts looking like a
fractional index.

 | My point is to consider the use of exclusive ranges instead of
 | inclusive ones. My instinct is that things like array slicing and
 | subsetting will compose better using exclusive ranges.

We are discussing half-exclusive ranges; 0 is a valid index.

 | Consider exclusive:
 |
 |   (let* ((n ...)
 |          (mid (/ n 2))
 |          (a (make-array default (list 0 n)))
 |          (first-half (array-slice arr (list 0 mid)))
 |          (second-half (array-slice arr (list mid n)))))
 |
 | versus inclusive:
 |
 |   (let* ((n ...)
 |          (mid (/ n 2))
 |          (a (make-array default (list 0 (- n 1))))
 |          (first-half (array-slice arr (list 0 (- mid 1))))
 |          (second-half (array-slice arr (list mid (- n 1))))))

You have convinced me that half-exclusive ranges look like the better
choice.  I have written some code just like your inclusive example.

How deeply ingrained are inclusive array bounds?  Looking through my
code-base I find two uses of non-0-based arrays.  In SIMSYNCH they are
used to provided a couple convenient storage locations associated with
an array.  And my sequence-comparison code in SLIB does because the
algorithm was originally expressed using negative indexes for one of
its arrays.  A couple hours of work can rectify these.

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.

Non-0-based array indexes also torpedo write/read invariance unless
the external representation includes the shape (instead of just the
rank).  None of the syntaxes discussed so far do this.

So I have removed pair bounds and ARRAY-SHAPE from SRFI-47.
http://swissnet.ai.mit.edu/~jaffer/srfi-47 has the latest until the
editor updates http://srfi.schemers.org/srfi-47/srfi-47.html.