(Perhaps) Remove Range/Loop Safety, So Folks Don't Have to Optimize

[jashkenas]

See the conversation here: http://news.ycombinator.com/item?id=3371171

Most of their work on the decoder went fine, but they ran into one area where (by default) CoffeeScript wasn't generating acceptable performance code, and had to coax it a little. Perhaps the original behavior we used to have is preferable? One commenter says:

I've programmed in dozens of languages, and I can't think of another
one where loops could automatically run either up or down depending
on the start and end values.

Not knowing CoffeeScript well, when I see this code:

n = -10
for i in [0...n] doSomething()

I'd expect it to call doSomething zero times. At least that's what I'd expect
in JavaScript or any of the other languages I've used.

[michaelficarra]

I like this solution (from @repsilat):

step = a<=b ? 1 : -1;
for (i = a; step*i < step*b; i += step) {
  doSomething();
}

[jashkenas]

@michaelficarra Interesting. Mind whipping up a JSPerf (or even better, a JSLitmus) for it?

[TrevorBurnham]

If breaking changes are on the table, then I'm for:

1. Assuming step to be 1 unless otherwise specified, eliminating the need for step = ... altogether.
2. Making for x in arr by -1 a valid way of iterating backward through arr.

[devongovett]

Here's the test: http://jsperf.com/coffeescript-looping.

Looks like the multiplication version is quite a bit faster than what we have now, but still much slower in some browsers than the code generated by using by 1. I think it would be a little confusing to have your loop not run when you thought it would go backwards and I think the current behavior is the correct one. We always treated the by 1 as an optimization. So I would say, switch to the multiplication version by default, and keep the behavior the same. People should then be explicit about their step values as an optimization.

@TrevorBurnham I believe for x in arr by -1 is a valid way of looping through an array. It generates this:

for (_i = 0, _len = arr.length, _step = -1; _i < _len; _i += _step) {
  x = arr[_i];
  doSomething();
}

which does seem to use a _step variable for no reason by the way, but that's another issue. ;)

Well... I guess it starts at 0 so it wouldn't work, but it is valid. :D Not sure it should start at the end if you put by -1... I guess it is natural.

[satyr]

Which issue was the one that proposed this (un)safety, by the way?

[TrevorBurnham]

@devongovett Look at that compilation more carefully. It starts at 0, stops at arr.length, and steps by -1. Unless arr.length is negative, the result is an infinite loop.

[devongovett]

@TrevorBurnham yup, realized that afterward and edited my post ;)

[TrevorBurnham]

@devongovett See #1208 for previous discussion.

[showell]

FWIW you can hate this transcompilaton even if you don't give a darn about performance.

for (i = 0; 0 <= n ? i <= n : i >= n; 0 <= n ? i++ : i--) {
  foo;
}

To borrow words from the HN comment, I can't think of another
programming language where loops could automatically run either up or down depending
on the start and end values.

It's just strange, and it sometimes leads to bugs for the degenerate case of algorithms.

I know that "by 1" can make the code deterministic, and I know that this regrettable decision may be hard to undo at this point, but it should be noted that this isn't just an optimization concern.

Minor edit: step -> by 1

[sophiebits]

Here's a new variant:

var step = 0 <= end ? 1 : -1;
var loops = Math.abs(end - 0);

for (var i = 0, j = 0; j < loops; i += step, j++) {
  Math.pow(2, i);
}

http://jsperf.com/coffeescript-looping/2

[ashtuchkin]

+1 that this is not just optimization.

Recently I was writing an autocompletion system, which included implementation of rather complex data structures (tries in node Buffers, anyone?) and ~30% of debugging time went to chasing cases where for cycle went backwards instead of not doing anything. This was my worst complaint of CoffeeScript, otherwise a brilliant language. I've ended with a lot of ugly statements like this (I wasnt aware of the 'by 1' trick):

  if a < b
    for i in [a...b]
      # Do something with i. 

Please, please, remove this unfortunate default. There is no other language I know of, that supports automatic forward-or-backward iteration and its a huge gotcha and source of confusion when implementing any real, non-trivial algorithm.

What I propose is:

1. Get rid of automatic forward-or-backward iteration at all. Always iterate forward. In 0.01% cases where the reverse is really needed, it could be written explicitly and be more understandable/supportable and less confusing for others.

2. Reverse iteration (which is itself rather rare) could be written, without the loss of comprehensibility as

  for i in reversed [0..3]

  # Equivalent  
  arr = [0..3]
  for i in reversed arr

  # Equivalent
  for i in arr.reverse()

  # Emits compilation error
  for i in [3..0]

3. Step of iteration must be positive even in reverse iteration, again to prevent confusion.

  arr = [0..3]
  for i in reversed arr by 2

4. To maintain consistency, this may also mean that arr = [a..b] would be empty if a > b. arr = [20..0] could emit an error like in the for loop above to prevent mistakes. To get the reversed array in these rare case I would suggest, again by the principle of least confusion, arr = [0..20].reverse()

Arguably, these changes will make reverse iteration and reverse arrays look slightly uglier in exchange to be more predictable. I think this is a fair change, considering reverse iteration is not so frequent and can/should be more explicit.

[al]

I'd also like to press that this is not merely a low priority optimisation issue. It (or at least its implementation) creates an inconsistency in the language/serious bug.

# A loop which terminates
a = 40
b = 30
lats1 = (lat for lat in [a..b] by 1)

# An infinite loop
a = 40
b = 30
c = 1
lats2 = (lat for lat in [a..b] by c)

For reasons that look to be related to this "safety" feature, this happens if the step is not literal and either the start or the end of the range is not literal.

[xixixao]

I have implemented the behavior I proposed on redux in this fork. I would be grateful for any feedback (primarily on the behavior)!

In short:
For ranges the iteration always goes from left to right and down or up depending on the step provided (up by default). There is no need for reverse iteration, because we can simply swap the range limits.

for i in [a..b] by -2 # for (i = a; i >= b; i -= 2)

For list-likes the direction is determined by the step

for i in xs by -2     # for (i = xs.length - 1; i >= 0; i -= 2)

I think the reverse iteration on arrays works well but I am still not sure about what should be the behavior for ranges, in and out, of for loops.