the Alien WHILE of QB64... a new feature written as old keyword

[TempodiBasic]

Hi friends

also here you must read before go down with discussion this
the changement to correct the estetic error is not useful like those of interchangeble EXIT FUNCTION  and EXIT SUB  and END FUNCTION  and END SUB

I want remark that
WHILE is not a QB option of EXIT command!
It is a QB64 feature http://qb64.org/wiki/EXIT
... so it would be _WHILE as option of EXIT command

so this code doesn't run in Qbasic

Code: QB64: [Select]

1. WHILE in$ = INKEY$
2.     IF INSTR("WASD", UCASE$(in$)) THEN PRINT in$ + "1": EXIT WHILE
3. WEND

and must be converted in  this using the DO LOOP

Code: QB64: [Select]

1.  DO WHILE in$ = INKEY$
2.     IF INSTR("WASD", UCASE$(in$)) THEN PRINT in$ + "1": EXIT DO
3. LOOP

It is not an error, but it is an error to pass EXIT WHILE as QB code!

Thanks to read

[SMcNeill]

I think the reason we have a WHILE and not a _WHILE here is just because of the fact WHILE is already a keyword.

The underscores are to make certain our new keywords don’t conflict with old QB64 code, and in this case, that’s not a concern.  QB64 wouldn’t allow WHILE as a stand-alone variable name, and it won’t allow it after an EXIT statement — so there’s no way we can invalidate existing code with it.

EXIT WHILE might be QB64 specific, but it seems much more natural than an EXIT _WHILE statement (at least to me), especially since we don’t have any sort of _WHILE keyword.  ;)

[Cobalt]

One other side note, EXITs in general are bad practice. They are a part of spaghetti code. as your not allowing what ever loop is using them to end normally and return as a finished line or section of code.

Not saying they can't be used, just that it might be a better way to think of your code as something that wants to flow smoothly from start to finish with out abrupt turns or changes.

So far I have yet to find an situation where the only choice was an EXIT to do something. At least with QB BASICs.

[bplus]

One other side note, EXITs in general are bad practice. They are a part of spaghetti code. as your not allowing what ever loop is using them to end normally and return as a finished line or section of code.

Not saying they can't be used, just that it might be a better way to think of your code as something that wants to flow smoothly from start to finish with out abrupt turns or changes.

So far I have yet to find an situation where the only choice was an EXIT to do something. At least with QB BASICs.

Before EXIT there use to be a GOTO someplace outside the loop, that WAS spaghetti!

[Qwerkey]

One other side note, EXITs in general are bad practice. They are a part of spaghetti code.

Oh, I thought that EXIT (as opposed to GOTO) to finish a FOR/NEXT, DO/LOOP, WHILE/WEND was terminating the loop properly: effectively it sets the loop to the finish condition(?).  In my most recent program, I did use EXIT for the first time.  I hate bad practice, however.  Is it bad practice?

[FellippeHeitor]

Hardly.

[RhoSigma]

Hardly.

+1

[SMcNeill]

Oh, I thought that EXIT (as opposed to GOTO) to finish a FOR/NEXT, DO/LOOP, WHILE/WEND was terminating the loop properly: effectively it sets the loop to the finish condition(?).  In my most recent program, I did use EXIT for the first time.  I hate bad practice, however.  Is it bad practice?

It doesn’t set it to the finish condition; it just GOTOs the end of it automatically.

WHILE x < 10
    x = x + 1
    PRINT x
    IF x = 5 THEN EXIT WHILE
WEND
PRINT x

The above will print 1, 2, 3, 4, 5, 5 on your screen.  The EXIT WHILE doesn’t make x = 10 (the exit condition).  What it does is basically the same as:


WHILE x < 10
    x = x + 1
    PRINT x
    IF x = 5 THEN GOTO WHILE_EXIT_NUMBER_1
WEND
WHILE_EXIT_NUMBER_1:
PRINT x

[Qwerkey]

Thanks, Steve.  I see that EXIT is just a brute force GOTO execution.  I see why Cobalt finds this "bad practice".

[bplus]

Thanks, Steve.  I see that EXIT is just a brute force GOTO execution.  I see why Cobalt finds this "bad practice".

So what exactly is "bad" about the practice of using EXIT?

It's an extra option to exit a loop, specially a FOR loop which would otherwise have to run through it's entire range or use GOTO or short circuit it's index.

What say Steve? Bad practice or not?

[SMcNeill]

So what exactly is "bad" about the practice of using EXIT?

It's an extra option to exit a loop, specially a FOR loop which would otherwise have to run through it's entire range or use GOTO or short circuit it's index.

What say Steve? Bad practice or not?

I don’t think so.  In fact, I think it keeps things much simpler and easier to understand many times, especially with nested events.

DO
    _SOURCE MyImages(Z)
    FOR X = 1 TO Wide
        FOR Y = 1 TO High
            IF POINT(X,Y) = ColorChosen THEN EXIT DO
        NEXT
    NEXT
    Z = Z + 1
LOOP UNTIL Z > UBOUND(MyImages)

Now, with the above, let’s say we have an array of images, and we want to search them in order to find the first one that contains a specific color.  With the above, all we need is the following:

IF Z <= UBOUND(MyImages) THEN
     ‘We found our match.  Z = the image, X/Y = the point where the color was found.
ELSE
    ‘That color wasn’t found.
END IF

Easy to read, follow, and understand.

Now, to do that same thing without the EXIT...

I’ll leave that as an exercise for others, as I’m on my iPad at the moment, but I just can’t think of anyway which you’d code that would be any simpler, or more efficient, than that.

[bplus]

Thanks Steve, searching was the first thing that came to my mind as well. I did not even consider loops within loops.
So that is why we have so many loop structures! So we could exit cleanly a multitude of them. ;-)

[TempodiBasic]

Premise I use EXIT as soon as I need it

but adding another condition on the cycle  and to the actions that must be done only until the cycle stops

like here:

Code: QB64: [Select]

1. DO
2.     _SOURCE MyImages(Z)
3.     FOR X = 1 TO Wide
4.         FOR Y = 1 TO High
5.             IF POINT(X, Y) = ColorChosen THEN Done = true
6.         NEXT
7.     NEXT
8.     IF NOT Done THEN Z = Z + 1
9. LOOP UNTIL (Z > UBOUND(MyImages)) OR Done
10.  
11. IF Z <= UBOUND(MyImages) THEN
12.     'We found our match.  Z = the image, X/Y = the point where the color was found.
13. ELSE
14.     'That color wasn't found.
15. END IF
16.  

It's an extra option to exit a loop

so this option can be put on the LOOP branch with control statements...

but do you think that adding conditions on the cycle can make the code slower than using EXIT ?
I don't know and I need of expert's opinion.

Thanks

[SMcNeill]

Your code wouldn’t work.  X/Y continues to change...

DO
    _SOURCE MyImages(Z)
    FOR X = 1 TO Wide
      IF NOT Done THEN
        FOR Y = 1 TO High
          IF NOT Done THEN
            IF POINT(X, Y) = ColorChosen THEN Done = true: XPos = X: YPos = Y
          END IF
        NEXT
      END IF
    NEXT
    IF NOT Done THEN Z = Z + 1
LOOP UNTIL (Z > UBOUND(MyImages)) OR Done
 
You’d need something similar to the above to get the same results (though more inefficiently).

Let’s say we have screens which are 4096x2048 pixels in size (4K HD), and we find the color instantly at point 1,1....

We’re not going to exit that Y loop early, so we do the IF NOT Done check 2047 more times.

We don’t exit the X loop early, so we do it 4095 and the IF NOT Done check there 4095 more times...

And then we FINALLY get to the LOOP UNTIL...Done where we exit... 

That’s over 6000 more repetitions of looking up the value of Done, NOTing it, checking if it’s 0 or not... 

...And, it uses 3 extra variables, which increases our program’s memory requirements/overhead: Done, XPos/YPos (to preserve the X/Y value when we find the match)....

.
.
.

In the end, isn’t it rather obvious which would be less complex to code, and more efficient at the same time?

[TempodiBasic]

I agree with you Steve

1. it is more expensive in typing and in use of memory and in debugging (IMHO for my experience)

2.

our code wouldn’t work.  X/Y continues to change...

I have missed to control the 2 FOR NEXT loop....
here my complete solution....

Code: QB64: [Select]

1. DO
2.     _SOURCE MyImages(Z)
3.     FOR X = 1 TO Wide
4.         FOR Y = 1 TO High
5.             IF POINT(X, Y) = ColorChosen THEN
6.                                Done = true
7.                                Y =  High
8.                                X = Wide
9.             END IF
10.         NEXT
11.     NEXT
12.     IF NOT Done THEN Z = Z + 1
13. LOOP UNTIL (Z > UBOUND(MyImages)) OR Done
14.  
15. IF Z <= UBOUND(MyImages) THEN
16.     'We found our match.  Z = the image, X/Y = the point where the color was found.
17. ELSE
18.     'That color wasn't found.
19. END IF
20.  

but it is a BAD practice also to change the counter/index of a FOR...NEXT cycle!   ;-)