Remove Ranges, introduce "from x to y"

[satyr]

tl;dr

Introduce infix to (with optional by) and replace current ranges with it.

intro

The pseudo ranges may look nifty in the first glance, but I think
they've become the bad parts in CoffeeScript.

proposed syntax

i for i in x to y by z
a = [x to y]  # can be by-ed as well
# no slice/splice

instead of

i for i in [x .. y] by z
a = [x .. y]
b[x .. y] = c[x .. y]

why current ranges are bad

Because they

• behave wildly different in different contexts.
  • array / array comprehension / loop range / slice / splice
• have awkward syntax.
  • (i for i in [.0 .. .2] by .1)
    • Parses as [(0)...(2)].
    • Looks ugly too.
• generate inefficient code or are inferior syntax sugars.
  • x = 1; y = 5; [x..y]
    • This is because it has to determine the direction dynamically. to-by would have a fixed step and thus generate better code.
  • Slicing is broken (or less versatile than .slice)
    • '012345'[-3..-1]
  • Splicing is broken (and less useful in general)
    • a = [0..5]; a[1..-2] = [42]
    • Ruby
• can be exclusive, but this is a confusing feature (especially with the look). We can live without it by simply subtracting from the right operand (since we only have numeric ranges).
• are confusing in the presence of splatted arrays: [x...,y]

edit: removed cup links that no longer work.

[StanAngeloff]

By no means criticising, but here are my thoughts:

behave wildly different in different contexts.

List of 1 to 5 [1..5], expand list to values list..., loop values 1 to 5 for [1...5], slice list values list[1..5]. I've realised it's much more consistent than it first looks.

(i for i in [.0 .. .2] by .1)

So does (i for i in .0 to .2 by .1). Much better to just add those zeros back in.

generate inefficient code or are inferior syntax sugars.

Agreed, but to-by is a new syntax so it can easily be back-ported to be [x..y by z].

Slicing is broken (or less versatile than slice)
Splicing is broken (and less useful in general)

How does to address this?

can be exclusive

I hate remembering which one is which. More dots -- inclusive, right? Wrong.

[satyr]

List of 1 to 5 [1..5], expand list to values list..., loop values 1 to 5 for [1...5], slice list values list[1..5]. I've realised it's much more consistent than it first looks.

The loop range supports by, others don't (the brackets look out of place too). Negative values behave different in slice/splice. a... is not a range.

How does to address this?

By removing them.

I hate remembering which one is which. More dots -- inclusive, right? Wrong.

Exactly.

[StanAngeloff]

I kind of like to, apart from removing slicing/splicing. I would hate to see these go away just because negative indices don't play nice.

[satyr]

apart from removing slicing/splicing

Maybe it could stay in the form of a[x to y], but how would you support by with them?

The fact that no splicing is used in the compiler itself (albeit the extensive use of splice in rewriter) is kind of telling its awkwardness I suppose.

[StanAngeloff]

I implemented a branch once (long time ago, dark ages) that supported both negative indices and by in slices and splices. It didn't get merged it because it was too awkward to have a[-10:-1:-2] and not to allow for a[-10] alone. Anyhow, I did it using __helpers so it certainly is possible. While CoffeeScript's core is a good measure of what is useful in the language, it certainly isn't the only place we should be looking for. I kind of agree ranged splices are not very common, but ranged slices are very useful, especially when combined in a destructuring assignment like so [apiKey, success] = response[1..]. Don't take this as the only place where they are useful cause it certainly ain't.

Back to the point, let's take out splices then and have a syntax for list[top to bottom].

[satyr]

ranged slices are very useful, especially when combined in a destructuring assignment like so [apiKey, success] = response[1..]

Well of course it's a must-have feature. But since JS's slice is quite strong as is, it'd end up with just an awkward sugar.

[apiKey, success] = response[1 to response.length - 1]
[apiKey, success] = response.slice 1

[jashkenas]

If we do pursue this direction, I don't think that by should be mandatory... We've already gone back and forth on this issue:

puts i for i in 1 to 10

... should be legit.

[satyr]

(with optional by)

[hen-x]

It'd be great to lose the .. vs ... ambiguity; I think inclusivity is a reasonable default. And while slices might look good the way they are, they do behave inconsistently. I don't like the fact that enumerable objects exposing a[b] don't necessarily support a[b..c], since it compiles to a slice call, which is only valid against normal arrays. So +1 for losing that too.

[zmthy]

What about having a til operator for exclusive?

[akva]

It'd be great to lose the .. vs ... ambiguity;

This is a great idea.

I think inclusivity is a reasonable default.

I'd prefer it to be exclusive by default, to be consistent with JS's slice. Makes it easier to remember

[hen-x]

To me, [3 to 7] looks like it means [3, 4, 5, 6, 7], with the 7 included. Of course, that's only my opinion. I see your point about slice, but since this proposal entails removing the range-as-subscript shortcut for slices, I think it's ok if ranges and slices have different inclusivity rules.

[satyr]

http://github.com/satyr/coffee-script/compare/master...to
1st stab without lexer/rewriter hacks (meaning to is a reserved keyword).

[jashkenas]

I'd like to merge this soon, and there's one more issue discussed in #coffeescript that should be mentioned here.

I'm not a big fan of our [1..5] literals (with this ticket [1 to 5]), which expand into loop comprehensions that generate the corresponding array at runtime. I use them occasionally, but hardly ever, and would rather get rid of them. If you want to generate an array from a range at runtime, you would write it like this:

array = (i for i in 0 to 100)

Sound reasonable? Anyone using the insta-arrays?

[akva]

+1 for removing [1..5] literals

I would still prefer for i in 0 to 100 to be exclusive though. Besides being consistent with slice it's also consistent with common idiom for (var i = 0; i < a.length; i++)