Exit Statement
An exit statement may appear inside a while-loop or a for-loop.
Note that phix uses break within a switch construct to resume control after the end switch, and it does not repurpose or overload that keyword to exit loops, unlike several other programming languages. Conversely, while desktop/Phix allows a (direct) exit within a switch statement, that becomes prohibited and generates a compilation/transpilation error under "with js", unless adequately nested, ditto (direct) break from within a loop, since JavaScript uses "break" for both loops and switch statements (and of course has no goto statement either, so we couldn’t even do that).
The exit statement causes immediate termination of the loop, with control passing to the first statement after the loop, for example
It is also quite common to see something like this:
If you happen to create a real infinite loop, when using p.exe keying control-c in the console will stop your program immediately.
However with pw.exe there may not be a console window, and your only option may be to terminate the process via Windows Task Manager.
To avoid that situation you may want to test (gui) programs using p.exe first, or create a console window at the start of the application, for instance by executing a puts(1,"") statement.
For legacy code only, the continue statement is similar, but causes the next iteration to begin immediately.
Control passes to the "end for" or "end while[+branch straightening]" statement. I will let you guess what this shows:
One trap for the unwary awaits: continue may trigger an infinite loop unless the required statement(s) in this kind of while loop are duplicated:
Note that phix uses break within a switch construct to resume control after the end switch, and it does not repurpose or overload that keyword to exit loops, unlike several other programming languages. Conversely, while desktop/Phix allows a (direct) exit within a switch statement, that becomes prohibited and generates a compilation/transpilation error under "with js", unless adequately nested, ditto (direct) break from within a loop, since JavaScript uses "break" for both loops and switch statements (and of course has no goto statement either, so we couldn’t even do that).
The exit statement causes immediate termination of the loop, with control passing to the first statement after the loop, for example
for i=1 to length(s) do if s[i] = x then location = i exit end if end forWhich is basically what find() does, except that actually uses a return statement rather than a local variable.
It is also quite common to see something like this:
while true do ... if some_condition then exit end if ... end whilei.e. an "infinite" while-loop that actually terminates via an exit statement at some arbitrary point in the body of the loop.
If you happen to create a real infinite loop, when using p.exe keying control-c in the console will stop your program immediately.
However with pw.exe there may not be a console window, and your only option may be to terminate the process via Windows Task Manager.
To avoid that situation you may want to test (gui) programs using p.exe first, or create a console window at the start of the application, for instance by executing a puts(1,"") statement.
For legacy code only, the continue statement is similar, but causes the next iteration to begin immediately.
Control passes to the "end for" or "end while[+branch straightening]" statement. I will let you guess what this shows:
for i=1 to 5 do if i=3 then printf(1,"%d is three\n",i) continue end if printf(1,"&d is not three\n",i) end forDouglas Crockford says "I have never seen a piece of code that was not improved by refactoring it to remove the continue statement", and I must agree. In some programming languages a continue expressly restarts the same iteration without (re-)incrementing the control variable or testing for termination. With that in mind, Edita/Edix now colour the continue keyword illegal, although technically it still works, and pwa/p2js issues a gentle warning. Certainly I believe an else plus indent makes it far easier to visualise the control flow.
One trap for the unwary awaits: continue may trigger an infinite loop unless the required statement(s) in this kind of while loop are duplicated:
if alldone then exit end if --\ either something += 1 --/ or both end whileObviously if you "continue" without somehow checking for completion/moving on, it will likely find the exact same reasons at the exact same place and therefore re-perform the exact same "continue", forever. In contrast, a for loop/continue automatically performs an implicit control-var increment.