I guess we’ve all seen Dijkstra’s famous argument that a range of natural numbers should be expressed using an inclusive lower bound and exclusive upper bound, and that, as a corollary, arrays should be indexed from 0. It’s a thought provoking little nugget of reasoning, though it fails to contemplate several objections, including that:
- The inclusive lower bound/exclusive upper bound combination (let’s call that a Dijkstra range) isn’t natural for a range which includes negative integers. The range
start<=i<=0would be written asstart<=i<1. Dijkstra ranges are nastily asymmetrical! - Zero-based indexing is infuriatingly inconvenient when accessing the last element of an array, or when indexing from the end of the array. Who here loves
array[length-i-1]? This inconvenience, at least arguably, outweighs the convenience of being able to write0<=i<lengthinstead of1<=i<length+1, and thus substantially undermines Dijkstra’s case for zero-based indexing, even if we accept his argument for Dijkstra ranges! - Two endpoints isn’t the only way to specify a range of integers!
Ceylon doesn’t have a traditional for loop, and we don’t iterate list elements by looping over the indices of the list. Nevertheless, we still need a way to express ranges of integers. Our solution to this problem is a bit different to other languages, and amounts to a partial rejection of Dijkstra’s conclusions, so it’s worth explaining the reasoning behind it.
Ranges
Our design is premised on the observation that we almost never, in practice, naturally find ourselves with an inclusive lower bound/exclusive upper bound combination. What naturally arises in our program is almost always either:
- two (inclusive) endpoints, or
- an (inclusive) starting point and a length.
Using a Dijkstra range, we can express either case without too much discomfort:
start<=i<end+1start<=i<start+length
Thus, we can view the traditional use of Dijkstra ranges as a sort of compromise between these two cases: a choice that makes neither option too painful.
But, of course, by clearly distinguishing these two common cases, it becomes clear that both case are amenable to further optimization. Thus, Ceylon provides two options for expressing a range of integers:
- The spanned range operator expresses a range in terms of its two endpoints as
start..end. In the case thatend<start, the range is ofdecreasing values. In the case thatend==start, the range has exactly one value. - The segmented range operator expresses a range in terms of its starting point and length as
start:length. In the case of a nonpositive length, the range is empty.
Thus, a traditional C-style for loop of this form:
for (i=0; i<length; i++) { ... }
is written like this:
for (i in 0:length) { ... }
Now, since integers aren’t the only things we can form ranges of, the .. and : operators are generalized to any type T that satisfies the interfacesOrdinal & Comparable<T>. So, for example, we can iterate the letters of the English alphabet like this:
for (c in 'a'..'z') { ... }
Slices
A closely related problem is that of “slicing” lists. Python uses Dijkstra ranges to express a slice of a list, so list[start:end] contains the elements list[start], list[start+1], ..., list[end-1]. For the reasons already given above, this is a reasonable compromise.
Ceylon goes one better, giving you the choice between:
- The span operator, written
list[start..end]for the elementslist[start], list[start+1], ..., list[end]. - The segment operator, written
list[start:length]for the elementslist[start], list[start+1], ..., list[start+length-1].
The span and segment operators are defined in terms of the rather abstract interface Ranged and therefore apply to more than just Lists. For example, the platform module ceylon.collection lets you express subranges of a SortedMap or SortedSet using these operators.
| Reference: | Ranges and slices from our JCG partner Gavin King at the Ceylon Team blog blog. |
My preference for specifying ranges as first included, first excluded is to keep consistent with non-integer ranges. One end must be excluded, or it’s impossible to specify adjascent ranges which do not overlap (by whatever arbitrary measurement precision you’re using – and it might not even be clear how much they overlap by, for example seconds or nanoseconds). For integers this is less of a problem, but there’s also no problem just following the same convention, as Python does.
Hi John: like in most other programming languages, Ranges in Ceylon are always ranges of discrete values, since Ranges are Iterable. We’re not considering continuous ranges of real numbers or rational numbers or whatever, so this issue does not arise.
One problem with the Python convention, as already pointed out, is how very common off-by-one errors are in code that uses the first included, last excluded convention. The convention is asymmetric, meaning that you have to apply a different reasoning pattern when you attempt to address elements from the end of the range.