Unfortunate non-mnemonic for ranges?

[gwhitney]

I always get 0..n and 0...n backwards because the one with more dots looks like it should include more, so I assume that's the one that includes the right endpoint and the one with fewer dots is the one that leaves it out. But actually it's the other way 'round. I doubt at this point there's much to be done about that, except I am hoping someone here might have another mnemonic to suggest to displace this "obvious" one from my head. Thoughts?

[bbrk24]

I think we have to keep these two, if nothing else for coffeeCompat mode. However, we could alias one or both of them:

• Rust uses ..= for the inclusive one
• Swift uses ..< for the exclusive one

[STRd6]

Civet inherited ranges from CoffeeScript which I believe got them from Ruby which got them from Perl which I think got them from AWK or maybe Bash sequence expansions.

Currently Civet, CoffeeScript, and Ruby have the same/similar range semantics.

I think Ruby semantics being well established is a good enough reason to keep it as is unless there is a much stronger and well known consensus in other popular languages.

Adding aliases could be a reasonable compromise as well.

[edemaine]

FWIW, a..b inclusive goes back to at least Pascal, which is one of the first languages I learned. So that's how I remember. 🙂

My best attempt at a mnemonic:

• .. is pronounced "up to"
• ... is pronounced "up to but not including"

Personally, I mainly use ..., as Python taught me well to think exclusive on the end. If you use one mainly, it's easier to remember what the other does.

We've discussed adding Python's : as an alternative to ..., which might help if you come from Python. But it conflicts with object notation.

[bbrk24]

[x..y] and (x..y) are a little ambiguous because they are, in some cases, actually valid JS:

const toString = 6;
console.log(5..toString); // function toString()

[edemaine]

Luckily, this is not the case in Civet: 5..toString() is invalid input. It is output for the more natural input 5.toString(). (I should document this in the Comparison page!)

I don't think [x..y) and (x..y] are harder to parse, thanks to the wonder of PEG parsing. But I guess I'll find out when trying to implement it. 🙂

[vendethiel]

[) and (] look very confusing to non-mathy people and simple tools, this'll require special support in most editors. Is a range syntax really worth breaking a lot of (or, perhaps, most) people's expectations?

[edemaine]

I agree that it will break bracket matching. Still might be worth it to some...

Some other options are presented here: https://softwareengineering.stackexchange.com/questions/64975/designing-the-perfect-range-literal

I don't think we can use ! to exclude an endpoint, but maybe some other notation...

[vendethiel]

Raku (ex Perl 6) uses 1 ..^ 6 for exclusive end. (and 1 ^.. 6 for exclusive start, as well as 1 ^..^ 6 if you want to be thorough...)

[gwhitney]

In case it helps anyone else, unless/until we get some "nicer" notation (I also like bbrk24's original suggestion of adopting both [a..<b] and [a..=b] from Rust and Swift, and by symmetry maybe [a<..b] and even in case of counting down [a>..b] and/or [a..>b]), my mantra is

"More dots, fewer elements."

[edemaine]

We have a whole new suite of slice notation via #1476!