[Implemented] NextFor and ExitFor statements

[oldefoxx]

I would like to see greater flow control without resorting to so many Goto commands. Since many branch instructions are located inside various
loop constructions, I would like to see the following commands implemented:

NextFor ;targest the Next statement for the current FOR loop
NextWhile ;ltargest the Wend statement for the current Wend loop
NextRepeat ;Targets the next Forever or Until for current Repeat loop

ExitFor ;jumps pass the next Next statement
ExitWhile ;jumps pass the next Wend statement
ExitRepeat ;jumps pass the next Forever or Until statement

ExitAll ;exit all currently opened loops (For, While, Repeat)

I would also like the While ... Until loop structures be usable together so that I can test both pre- and post- conditions on a single loop.

(Implemented as 'Continue' and 'Break')

[Karbon]

Just a "continue" statement that jumps to the next iteration of a loop would do for all loop constructs I think.. Requested several times before I think... It would be a nice thing to have!

[oldefoxx]

How many times has it been necessary to effectively perform an exit from a for, text a variable, exit from a Select, text again, and exit from a Repeat? That is the problem with just having a Continue statement -- it cannot be targeted. If I had my choice of exit commands, I could be inside that inner For loop and just say "ExitRepeat", and jump completely passed two intermediary tests and jumps. Of course I could still use a Goto, right? But if you are going to argue that Goto is adequate, then you
defeat the purpose of even having a Continue, with as little as it does.

And that is not even recognizing the advantages of speeding through a loop process by accelerating passed some of the embedded code by using NextFor, NextWhile, or NextRepeat. You can skip over a lot of conditionals and process steps in this manner, which improves the efficiencies of your program.

But while we are taling about Goto, I would like to see single-line conditionals, such as "If a Goto label", rather than:

Code: Select all

If a
  Goto label
EndIf

or

Code: Select all

If a : Goto label : EndIf

I don;t know why, but having to add that trailing 'EndIf' just bugs me.

[Flype]

on some language i see something like that :

On <condition> Goto Label

it could be better than

If <condition> Goto Label

because it doesn't need to redesign the 'If' statement inside the compiler and also inside purebasic editors (syntax rules).
What's your opinion Fred ? I'm agree with you if you think it's more a lazy feature than a high priority needed one

[D'Oldefoxx]

Not such a good thing. First, On Goto is somewhat archaic in nature. Second, the traditional form equates each address to an accessement of the condition in integer terms. So if you used this:

Code: Select all

On a Goto label1, label2, label3, label4, label5, label6, label7, [etc.]

[/code[

if a=1, you go to lable1.  If a=2, you go to lablel2.  If a=3, you go to label3. and so on.  If you had a value for a of less than one or greater than you had lables to match, you fell through the On statement and executed the next line of code instead.


You could bias "a" so that you could jump to and sequence of corresponding values.  by adding or subtracting an offset, you could make the On Goto work for you.  You could also make complex equations to force a to some integer value, such as a=(b=5) &1 | (b=12) & 2.  The trouble with this approach was that a TRUE situation had to equal a -1
value to permit the bit-wise AND (&) and OR (|) operators to function properly.  Many more recent versions not treat a TRUE as a 1 and a FALSE as a 9, without understanding the reason for unsing a -1 (all binary 1 bits) for its merit in this role.  Of course you can add an unary sign before a logical evaluation, like a=-(b=5) & 1 | -(b=12) & 2.

If you heard of ON GOTO, you probably also heard of ON GOSUB.  Same thing, only you returned to the next line on exit from the subroutine.  This also fell out of favor as the greater untility of Functions and Subs became apparent and subroutines fell out of favor.  You could build modules with procedures, but not with subroutines.  

[Fred]

'Break [x]' and 'Continue' commands will be added for the next version.

[Kale]

'Break [x]' and 'Continue' commands will be added for the next version.

Woah! Very nice! Ta Fred