if your in a function you can "return"?

I was just reading the other day that Lua 5.2 came out and has support for goto statements (I know it's heresy just to mention goto's) among other things. You could more or less simulate continue with goto if Codea moves to 5.2.

Not sure if TwoLivesLeft has any plans to put Lua 5.2 on the roadmap for Codea though.

goto is evil.

But upgrading to 5.2 won't force me to use it. :-) and y'all can learn by getting burnt.

It should be fully backward compatible, and I see "new library for bitwise operations" in the changelog, SWEET!

In the beginning there was BALR R1, R2

Goto is easily misused, but it presents some elegant solutions to problems that have to be solved with temporary state variables. Particularly loops with multiple exit points.

What popular programming languages have goto? C, C++,Go, Fortran, Ada... and that's just off the top my head :-)

Stay in the same scope? No, there's no need for goto in that case. Stay in the same function? Usually, but with nearly any interpreter it's important to be able to get back to the REPL to recover from an error at any stack depth. In C you do it with setjmp/longjmp, in Lua with xpcall.

Agreed - except that misuse of goto by the many is a poor reason to forbid it for the 1% of cases where it does make your code more readable. ;-)

I agree - with reluctance.

Goto should be in there because they put it in 5.2, end of story. But - it wasn't in 5.1 and earlier, and we were fine.

I don't like it not because it could be misused - but rather because I view Codea's place in the world (other than making money for twolivesleft) as an educational/hacking/play tool. I have the job I have today because I got an 8 bit computer and I spent a ton of time learning it, and until Codea came along, that opportunity was gone; I can see a kid spending time with Codea and learning to code and years from now pointing back at it, in the same way I point back at my Atari 400, and saying "That's the thing that put me on this career". And it would just be nice if they learned to do it without goto.

Because I had goto. I learned BASIC. And it was fun, and good, and I had to re-learn later how to do it "right". And I would spare the next generation that - bad habits die hard.

Good point.

Disagree there - stock Lua, most recent stable version, is the way to go. Compatability with regular Lua code is very important - I would hate to run into libraries we can't use because goto was eliminated for ideological reasons.

Just wanted to mention this: Why I don't want goto():

Nat, but changing loops into recursive functions makes the code messier, longer, less natural. The main advantage of continue to me is that the code becomes shorter. Continue statements are never strictly needed, they're just nice and useful.

Edit: break statements are also not needed, but lua has them. It is truly bizarre to me that lua doesn't have continue.

The only use of goto I can condone is for breaking out of a nested loop structure.

loop a
   loop b
     if done
        goto break_loop

break_loop:

Its cleaner than using a temporary variable and checking it in each nested loop's invariant (especially so if you have even more nesting then 2 levels).

That said, lua uses gotos internally when the error function is called from a cfunction, jumping outside of the interpreter and printing the error. They have wrapped it in a well defined interface, with well defined conventions like always putting a return after the error function to indicate that your calling function will not continue executing, even though the return will never be called, so it works well.

It seems like the most elegant solution in that case.

When it comes to continue, you could structure your code like so: Instead of:

loop a
  do stuff
  if skip
     do the other thing
     continue
  end
  do more stuff
end

it could become

loop a
   do stuff
   if skip
      do the other thing
   else
      do more stuff
   end
end

There is no real need for continue as far as I can see, though there are some cases (multiple exit points) where continue would probably be nicer. If that is the case though, you are probably better off using Tail Recursion like @Nat mentioned and using return instead of continue. I've always found recursive functions easier to reason about anyway, but its a matter of opinion.