Designing the perfect range literal

Question

I've been thinking on how I would go about designing the "perfect" range literal if I were to do design a language. For you that don't know know a range literal in a statement that represents a range of values, like 1-4. They're most commonly used in for/foreach loops

There seems to a couple of issues one should take into account

• Support for inclusive and exclusive ranges, tacking on +1 or -1 to endpoints seems a bit fugly and errorprone.

• Support for stepping, so you can make a range of even or odd numbers for instance

• Readability, it should be readily apparent what the range literal describes

• Unambiguity, it should be perfectly unambigious what the range literal describes

• The default should probably be from inclusive to exclusive since that's what's used in most cases for looping over arrays etc.

Anyways, one example of range literal I've seen is Ruby which is in the form of 1..3 for an exclusive (on the end) range and 1...3 for inclusive (on the end). You can also do 1..10.step(5). After careful consideration I found however a couple of things I didn't like about that approach (from my limited knowledge of ruby)

1. You can only describe inclusive and exclusive for the end. While describing most scenarios it does seem a little inconsistent.

2. Varying by just an additional . seems like a recipe for making it hard to see whether a range is inclusive or exclusive. I don't know about you but dot's tend to become something of a blur :)

3. Adding method like notation for ranges seems to mix the notion of a literal with that of a class which seems a bit inconsistent (even if ranges get compiled to a class)

Anyways, after pondering different alternatives. I came up with this

• [5..1] 5,4,3,2,1
• [1..5[ 1,2,3,4
• ]1..5] 2,3,4,5
• [0..5..20] 0,5,10,15,20

and so forth. I like it because [ normally denonates a set and this kinda fits into that, even though this in contrast to a set would be ordered.

One thing I'm a bit torn about though is making the exclusive/inclusive indicators mandatory or not, ie if you write just 1..5 the default would be 1,2,3,4 since it's the most common case with arrays etc. It's easier and more readable, but less specific and if you had to write [1..5[ you learn early about how they work.

So what do you think, did I cover most bases, overlook something? would you make the [] mandatory? Would you design range literals differently in your programming language?

Candidates

• bracket style: [0..10[ , with step: [0..5..20[
• interval notation: [0..10) with step: [0..5..20)
• exclamation for exlusive. 0..!10, with step: 0..5..!20
  • with different step. 0..!20, 5
  • however, that would make the default *0..10' inclusive-inclusive
• wordy: [0 to !20 by 5]

I must say that my favorite aestically so far is 0..!10 and 0..5..!20, I just wish the default 0..10 to inclusive-exclusive would be more logical

Answer 1

Why invent what already exists in Mathematics?

Interval Notation

That should cover your 'Unambiguity' point as it already exists.

Your only issue would be defining the stepping. Maybe something else in mathematics can help with that?

Answer 2

Have you seen Haskell ranges ? Their idea for steps is similar to your (in the middle) but indicated with a syntactic difference (from @luqui's answer):

[1,2..10] = [1,2,3,4,5,6,7,8,9,10]
[1,3..10] = [1,3,5,7,9]
[4,3..0]  = [4,3,2,1,0]
[0,5..]   = [0,5,10,15,20,25,30,35...  -- infinite
[1,1..]   = [1,1,1,1,1,1,1,1,1,1,1...  -- infinite

I find this notation very intuitive: you start enumerating and skip over the body to mark where it should end.

It does not cover the case for "exclusive", but frankly, I'd rather be clear about the behavior once (specify which bound is inclusive and which is exclusive), and expects user to make adjustements unless the syntax is extremely clear (and does not confuse language agnostic editors).

Answer 3

You should read about list comprehensions in languages that offer them.

Python, for example, covers your cases pretty nicely with the range() function and the list comprehension for cases too complex to express with range().

Answer 4

I believe your notation is far away from being unambigous. Intuitively, [0..5..20] doesn't look to me like a range with step width = 5. It even fails in some corner cases: what about expressing the set (0,2) - [0..2..2] or what should I put in the middle?

I think that Python's slice notation is a solid approach: [start:end:step] (step being optional).

If you really need support for exclusive and inclusive ranges, I'd use standard range notation (i.e. using ( and [) unless this introduces syntactic ambiguities in your language.

Answer 5

I think when you're setting a third increment value you're better off adding this a the end, rather than the middle, since this is an optional value, and seems more intuitive to seasoned programmers than adding an optional 3rd argument in the middle.

so instead of [1..5..20] you could do something like [1..20][5] or [1..20,5]

Answer 6

• [1..5[ 1,2,3,4
• ]1..5] 2,3,4,5
• ]1..5[ 2,3,4

Why not just use [1..4], [2..5], [2..4]? Excluding Ranges don't offer much benefit. You don't need to write MIN+1 or MAX-1, yes, but they don't prohibit it anyway. Too much variation, imho. My language of choice, scala, has (1 to 3) and (1 until 3) [=(1 to 2)] but it just confused me at the beginning. Now I always use 'x to y' and know therefore, that the option which I don't use is the excluding one, but of course I don't benefit from an Option I don't use.

• [5..1] 5,4,3,2,1

is of course (1 to MAX) (x => y = (MAX + 1) - x) but that is much boilerplate and not userfriendly.

• [0..5..20] 0,5,10,15,20

is of course (0 to 4) (x => y = x * 5) is not so much boilerplate. Disputable.

Answer 7

What about something like this:

• [5..1] 5,4,3,2,1
• [1..5][i,e] 1,2,3,4
• [5..1][i,e] 5,4,3,2
• [1..5][e,i] 2,3,4,5
• [1..5][e,e] 2,3,4
• [0..20] by 5 0,5,10,15,20

The i and e in the second pair of square brackets indicates if the begining or ending of the range is inclusive or exclusive (or you could use incl, and excl if you want to be more clear). the by 5 indicates the stepping interval. The first and last example are inclusive of the first and last value, so I omitted the [i,i], which I think would be an OK assumed default behaviour.

Default values could be [i,i] for the inclusive/exclusive specifier and by 1 for the step specifier.

Normally I'd have suggested the standard notation involving ( and [ as mentioned by @Dan McGrath , but I agree that in code this could look confusing.

Answer 8

I wouldn't use the '[1..5[' form for one of the same reasons you would avoid mixing parens and braces - it will confuse most existing editors' brace matching. Perhaps use a marker inside the braces, like '[1..|5]'.

The other thing to consider is the behavior of methods to get the limits. For instance, 'begin'/'end' vs. 'first'/'last' vs. 'min'/'max'. They need to be sane for both inclusive and exclusive limits, as well as those with a step size.

Answer 9

Ruby has notation and a Range object that works. Essentially it looks like this:

1..5  # range 1,2,3,4,5

With Ruby, step size is not a function of the range, but rather a function of iterating through the range. We could use the same range above and iterate through it differently if we wanted to:

(1..5).step(3) { |x| puts x }
(1..5).step(2) { |x| puts x }

So here are things you may want to consider:

• Adding language support for inclusive/exclusive endpoints can be problematic. If all ranges are inclusive (Ruby's choice), then the developers will adjust the endpoints of the range accordingly. How do you represent the endpoints inclusiveness or exclusivity in a way that is both visually unambiguous and unambiguous with a simple parser grammar?
• Are you using the range for more than just iterating? Common examples include range comparisons, splicing, value in range comparisons. If so, how do you represent those possibilities? (See the link to the Range class for ideas to each of these examples.)

BTW, ranges are rather nice if you allow them to be included in a switch statement like Ruby does:

switch(myval)
    when 0..33 then puts "Low"
    when 34..66 then puts "Medium"
    when 67..100 then puts "High"
end

I'm not saying that Ruby's range object is the end all and be all, but it's a working implementation of the concept you are talking about. Play with it to see what you like, dislike, and would do differently.

Answer 10

One solution which I'd certainly consider is using operator overloading to allow e.g.

1+[0..3]*5

It wouldn't necessarily be immediately transparent to everyone, but once they stop and think I hope most programmers would understand it, and people who use the language regularly would simply learn it as an idiom.

To clarify, the result would be [1, 6, 11, 16], lifting the multiplication and then the addition over the range. I hadn't realised that it might be ambiguous to Python users; I think of ranges as subsets of total orders rather than as lists. and repeating a set doesn't make sense.

Answer 11

And the winner is

Sorry for chosing my own solution, I really appreciate all the comments and feedback and please do critize this solution if you find anything wrong with it

So I decided to go with:

0..5           = 0,1,2,3,5
0..5..10       = 0,5,10
..3            = 0,1,3
!0..!5         = 1,2,3,4
3..            = 3 to infinity

segmented ranges
-
0..5,..5..20   = 0,1,2,3,4,5,10,15,20
0..3,10..5..20 = 0,1,2,3,10,15,20

As you can see inclusive is the default on both senses, it's what makes intuitively most sense especially when using stepping. You can use ! to make an end exclusive.

The downside is that normally you want to use exclusive when working against an array, but then again, most times you should probably be using something like for-each in those cases. If you really really need to work against the index the parser could recognize when you possibly forgot the exclusion marker on the end and issue a warning

I went with using .. on both sides of the step variable instead of using comma or anything else since that's what looked cleanest and I hope is the most readable.

I also threw in some syntax with comma's to be able to make ranges where different parts have different steps