Christmas Fun

[stevepoole]

Hi Folks,
Just been reading the TURBO manual, section 2,6,3 : WARNINGS & Auto-Corrections :

Tubro says : always prefer END FOR instead of NEXT, (the latterof which should only be used for 'loop epilogues').

NEXT was only included in SuperBasic for a 'degree' of compatibility with other Basics.

NEXT is too powerful : It can jump out of a subroutine or other loop2 and back out to a Global loop1. (try it! it can be useful here).

Used within an IF.......NEXT statement, it is best replaced by an IF.....GOTO ('END FOR ' line_number).

Be careful with NEXT....... Regards, Steve.

[Andrew]

It looks like when the specific case of 2 or more nested FOR/NEXT loops terminated with NEXT are used inline (i.e. not in a PROC/FN) *and* there is a procedure or function, then the outermost NEXT of the nested inline FOR loops must be changed to a END FOR. It doesn't matter if the loop control variable is a float or integer. Possibly Turbo is not keeping track of nested NEXTs correctly, possibly a 1 to n versus 0 to n-1 count error within Turbo in keeping track of labels. I admit I have no idea why the nested loops compile correctly if there are no procedures, but stop compiling correctly when there is a procedure!

I quickly tried it on JS ROM in QemuLator to check it wasn't something specific to SBASIC. Apart from the fact that SuperBASIC doesn't allow integer loop variables (just change c% and d% to c and d in the example), the same problem occurs, so it is specific to Turbo, and not some form of tokenisation error in S*BASIC for example.

Not quite sure why my earlier attempts meant I had to SAVE and reLOAD the program for it to work - it's possible there's something else in there which Turbo doesn't like.

Thank you Dilwyn - this clears the mistery!

I have tried before to use END FORs as Martyn_Hill suggested in a previous message, but I have not saved and reloaded the program and the compiling failed.

[dilwyn]

I suspect that Steve is right, that basically if we stick to the script of using FOR / END FOR in QL style instead of FOR / NEXT Spectrum style we are protecting ourselves from this condition.
By following what Andrew had said he'd already tried, a clue was in the Turbo report file, something like Warning: End For assumed at line ... (as I think Martyn was onto in his message). So Turbo probably was detecting the absence of an END FOR and trying to add an explicit one. And probably kept trying to add or find one until it ran into a DEF PROC line and giving up.
At least this is now documented here in case one of us runs into it again.
(If this message is garbled at the edges, it's because it's typed on an Android - not Andrew'ed! - phone and the typing box still goes off the right edge of the screen so typing is blind there)

[Derek_Stewart]

The cotrect usage is clearly defined on the Superbasic / Sbasic Reference Manual.

So no real excuse for not knowing about the correct syntax.

[bwinkel67]

So I modified it a bit so that it loops...it prints all the screens first (also included turbo toolkit with boot program). Plus, I fixed it to work with JS SuperBasic. It's called Claus_bas:

Santa2.zip

(43.02 KiB) Downloaded 91 times

...and a 128K version on MDV (had to remove the last screen) called Claus_128K_bas:

MDV.zip

(43.33 KiB) Downloaded 108 times

[bwinkel67]

Here is an animated GIF of the repeating part. Merry Christmas!

Claus-small.gif (492.5 KiB) Viewed 1581 times

... and a larger one (click to see it animate)

[Cristian]

So nice!

[XorA]

QL art that is not green and red \o/

Looks awesome!

[Andrew]

The 4 screens:

[vanpeebles]

Wow that looks great