FOR NEXT loops - any issues?

[Dennis]

Is it only me or are others experiencing problems for FOR NEXT loops?

I am busy converting 100% working code from another BASIC to Liberty Basic. In three instances now, I have been getting illogical and unpredictable results running the LB program. I traced the the problems and found that they were due to FOR NEXT loops not behaving as they should. I replaced the FOR NEXTs with good old-fasioned incremental counter/goto loops and the problems went away. When I bring the FOR NEXT loops back again, the problems came back. 

As a result of the issues, I am now wary of using FOR NEXT and have reverted to the traditional looping technique rather than use FOR NEXT.

I tried to establish a FOR NEXT pattern causing the unpredictable results but sometimes they work and sometimes they don't. The best that I can come up with is that when the FOR NEXT loop contains complex (nested) IF statements, I have issues.  Although i avoid goto statements, I have also found that goto or return statements inside an if which is in turn inside a FOR NEXT loop sometimes also causes strange things to happen.

This is not a showstopper issue as I can do a workaround with incremental counters and goto staements but it is a nuisance. If I now hit an "unpredictable result" situation I immediately suspect that it is a FOR NEXT and replace it with a workaround. That invariably solves the problem

I am curious to know if anybody else has had similar experiences.

[tsh73]

I am curious to know if anybody else has had similar experiences.

It is known that GOTO out of nested loops confuse LB
(btw not only FOR/NEXT but WHILE/WEND as well)
(looks like internal stack corruption)
This is just implementation trait of LB. (was designed that way)
So play safe and use flag variables and EXIT FOR, and all should be OK

Except this, I do not aware of any problems with FOR loops in LB.
Ah, wait
Do you use something weird as FOR index variable? Global var or function parameter?
I remember seen weird things then - but this is really weird usage, should not really happen.

Really you should provide some examples.

Because for me having
for i =1 to 2 step 0.1
print i
next

never get to 2 looks illogical - but it might be totally another kind of illogical you mean.
(yes I know what .1 is infinite periodical fraction in binary)

[Walt Decker]

Although i avoid goto statements, I have also found that goto or return statements inside an if which is in turn inside a FOR NEXT loop sometimes also causes strange things to happen.

Is the target for the goto inside the for-next structure?  If not chances are you are breaking the LB code.

I assume that the RETURN is in response to a GOSUB and the GOSUB target is outside of the FOR-NEXT structure.  If not you are breaking the LB code.

[Dennis]

Hi Anatoly
Thanks for responding. The programs are far to large to share and when I try to reproduce the problems in a smaller code set, all goes well.
I think the problem is the nested loop issue that you mention and I have a feeling that it sort of also happens with nested IFs.
I use straight forward indexes - nothing strange. I think the nested loop/nested IF is where the problem is.
I will experiment a bit and come back to report.
Regarding the use of goto within a loop, I rarely do this but I do issue RETURN statements to exit a subroutine. I mostly use EXIT FOR
The issue is not critical but it is very irritating when it happens

[Dennis]

I read your message again regarding GOSUB and GOTO - I do not do anything strange that I have not done in other BASICs...

I will double-check and take care....

[tsh73]

Have a look
libertybasiccom.proboards.com/thread/1551/next-loop-counting

[tsh73]

Btw never heard of any nested if problems

[Rod]

A simpler answer would be that you are messing with the for next loop counter within the for next code. The counter needs to be unique, so if you call it i don’t set i anywhere in the code.

[tenochtitlanuk]

I have no troubles either. LB has the 'exit' statement to cleanly leave structures like for/next.
This command causes the program to exit a looping structure such as DO, FOR, WHILE. It also causes the program to exit subs and functions.

[Stefan Pendl]

In general using GOTO or RETURN to exit a loop is not permitted in LB.
In LB a loop always needs to be exited by using EXIT [DO/WHILE/FOR].

[Carl Gundel]

Aug 13, 2021 7:44:21 GMT -5 Stefan Pendl said:

In general using GOTO or RETURN to exit a loop is not permitted in LB.
In LB a loop always needs to be exited by using EXIT [DO/WHILE/FOR].

With LB5 this is much less of an issue.  However, it isn't possible to jump into a structured loop in LB5 because the branch labels are scoped locally inside loops to prevent it, and this is by design as it should be.

[Dennis]

Thanks for all the comments and help - much appreciated.

I had another look at the code causing the problems. In answer to all the suggestions given;

1. I do not mess with the index - I am strict about that and very careful.
2. I do not use GOTOs to exit loops - never!
3. And I definitely do not jump into a structured loop from elsewhere.

After 52 years of programming, I definitely do not do any of the above. They are no-nos in all similar languages BASIC, FORTRAN, etc.

What I do however is that I use nested IFs within structured loops and sometimes exit a loop with a RETURN if I am in a subroutine and a condition is met in the nested IF.

I will go with what Carl says about LB5 and the use of a RETURN.

Please note that the code I am referring to has been working perfectly for the past 22 years but was originally written in other BASIC implementations. I am now converting everything to LB and intend staying with it.

I have hit a number of quirks in LB which were not issues with other BASICs. No problem though - I mnanaged to work around them although irritating...

[tsh73]

I have hit a number of quirks in LB which were not issues with other BASICs. No problem though - I mnanaged to work around them although irritating...

Really, I think it could be useful to somebody.
How about shed some light on these issues?

As for RETURN from a loop
Take this code, run debugger, put cursor to commented line and select "run to cursor".
Then step over a fiew times.
for i = 1 to 4
   print "i=";i
   gosub [chk]
next
print "over"
end

[chk]
   for j = 1 to 3
       print "   j=";j
       if i=3 and j=2 then
           return  'in debug, run to this line
       end if
   next

return


Apparently stack gots messed up - return executes OK, but Next in main program moves execution into FOR of subroutine.

But if I change GOSUB/RETURN with CALL/SUB
call chk i
'----
sub chk i
   for j = 1 to 3
       print "   j=";j
       if i=3 and j=2 then
           exit sub  'in debug, run to this line
       end if
   next
end sub


everything goes OK
(may be sub has it's own stack that get discarded on exit)

[Dennis]

Ahhhh Anatoly, I think you have hit the nail on the head. I will try CALL SUBs instead of GOSUB.

Quirks? Most have been commented on before by others but here is what I have had to do some rethinking about so far:
1.  mid$ on the left side of an expression i.e., mid$(WorkRec$, 25, 5) = "xxxxx" or mid$(StrVar, NumExpr1[, NumExpr2]) = StrExpr
2   ltrim$ and rtrim$ as two seperate functions although I like the trim$ function.
3   The QBasic "CHAIN" command - useful to create an overarching control program which "calls" other programs and returns.
4   USING with more formatting options (See QBasic LPRINT using....)
5   More control over the printer i.e. the ability to send commands to a printer to set up landscape or portrait without user intervention. 
6   The FOR NEXT issue we are discussing in this thread
7   Some controls such as spinner, month calendar, progress bar, status bar, etc. I understand that some of these are in LB5

Regards

[Brandon Parker]

Yeah, a GoSub/GoTo are branching mechanisms to code defined after branch labels. I have always understood them to be scoped at the current level of the stack (i.e. they do not have their own stack space) which is why you can "see" variables that exist in the scope prior to a GoSub/GoTo branch within the subsequent branch structure. Subroutines (Sub...End Sub) are different in the fact that they do have their own stack space and have their own local space which is by we have to pass variables into them either ByValue (normal method) or ByRef (referring to the variable in the previous scope).

If you replace the "Return" in Anatoloy's code with an "Exit For" then the code executes as I would expect it. Returning from within controls structures is not always a good idea and is definitely discouraged in many languages in favor of correctly exiting the control structure and only having one "Return" place at the end of the Function/Sub/Label (or whatever...).

As for your list of quirks, remember that every language is different and many things that languages do have in common are implemented in differing ways. I can't really see any brick wall for any of the items you have discussed. Even the #7 items can be accomplished using the Windows API with a bit of work.


{:0)

Brandon Parker