This page is part of the web mail archives of SRFI 47 from before July 7th, 2015. The new archives for SRFI 47 contain all messages, not just those from before July 7th, 2015.
| * To: srfi-47@xxxxxxxxxxxxxxxxx | * Subject: consider exclusive index ranges | * From: Ray Blaak <blaak@xxxxxxxxxxxxxxxxxxxx> | * Date: Thu, 13 Nov 2003 10:06:41 -0800 | * Delivered-to: srfi-47@xxxxxxxxxxxxxxxxx | | 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.