Loop up to a limit then throw

[STRd6]

Sometimes it is nice to have a while true that throws after a number of steps is hit. Maybe there is a good shorthand for something like that.

loop 1000
  break if sum > 999
  sum += it.value
  it = it.next
then throw new Error 'limit hit"

Ideally this same mechanism could be used after any loop completes. I guess it is semantically equivalent to Python's else and maybe we should go with that but the else naming is not immediately intuitive.

[edemaine]

Lots of nice ideas here!

First, iterating n times. CoffeeScript has for [0...1000] (with no i in) to do this kind of iteration. We should support that for CoffeeScript compatibility. But I like loop 1000 as an even more succinct form.

Second, executing code when a loop doesn't break. (This should apply to all kinds of loops.) This is indeed Python's else. I think we've talked about this before, and both then and else could be argued, which is maybe problematic. My worry with then is it sounds like something that always comes after, like finally. But I guess you could think of it specifying what to do after the final iteration, and break escapes that. Fundamentally, perhaps the issue is that break is sometimes used when something is found — then else makes sense — and sometimes used to escape the loop — then then makes sense. I could actually see wanting both:

for item of iterable
  break if match item
then/else
  console.log 'Found!'
else/then
  console.log 'Not found :-('

Somewhat crazy idea: if we replaced break with break bool, then the then clause could apply if bool is truthy, while the else clause could apply if bool is falsey. I guess break by default would be equivalent to break undefined/break false, which would match your semantics but be the opposite of Python. break true would give Python semantics.

Related, continue value could be useful to add value to the list accumulated by a loop, but skip the rest of the body of the loop. Of course, both of these ideas are incompatible with labels, but maybe we could detect whether the argument is a label and treat those specially?

[edemaine]

I just reread @STRd6's original post here, and realize that I misread it the first time. The original intent is that the then block executes upon break. This is actually consistent with Python's else block, which executes when we don't hit a break.

So maybe there isn't a confusion over which case is then and which is else, and we should just use those block names, as re-suggested in #1247:

for ...
then // break
else // no break

I like that this could be read as if there was an "if there was a break" before the then and else blocks. And consistency with Python is great. What do you think?

I think then and else would also override the return value for the loop. The for results array would be returned except when there's an else clause. And maybe one day we can access for.value in the then and else branch to enable more general modifications to them.

[edemaine]

Oops, just read #1247 (comment) which argues that even else is confusing. Never mind.

[edemaine]

According to #362, the original example would be written like this:

loop 1000
  break if sum > 999
  sum += it.value
  it = it.next
unless break?
  throw new Error 'limit hit"

I do find the meaning clearer (no then vs else ambiguity), though it's obviously a bit more verbose.

[edemaine]

I was looking at implementing loop 1000, and realized that this already has a meaning, namely, while (true) 1000. We could still make it mean something different when it has an indented block (or then) after it, but wanted to make sure: do we still like this notation? Or perhaps something like for 1000 would make more sense? Hmm, or is that inconsistent with for [0...1000]? (What would for x mean?)