What should happen when this code is run?



Now what would you expect to see when this is run?



The final question is how would you handle this if you were writing a BASIC compiler?

It takes a twisted mind to try to write a compiler; it requires a really twisted mind to thoroughly test one.

I would expectfor the first andfor the second. Did I win?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I do not think there is one right answer.

Your answer for the first is the intuitive answer for a BASIC interpreter. It just blindly executes code until it encounters the "NEXT" statement, so that becomes the "bottom" of the loop.

So far, I have only tried it at https://yohan.es/swbasic/ and it gives the same result as you.

For the second one, it gave just

1540

What to do when the loop is not executed is subjective. Possibilities include:

* look forward only, expecting "properly" structured code
* look both forward and backward for the nearest one
* scan the code without executing it except for following any "GOTO" statements. That is ill advised at best as the bowl of spaghetti may include conditional code with many possible branches

I would expect a compiler to be more strict in several ways than an interpreter, and generally to accept fewer code constructs. It is natural for a compiler to prefer properly structured code and strong typing, whereas it's relatively easy to write an interpreter to be more flexible in both of those respects (at the expense of speed).

However, it is also entirely possible to write a "threaded code" compiler which works very much like an interpreter, but without the overhead of parsing each source line as it is encountered. Such a compiler would emit code that runs more slowly than well optimised code, but can be more flexible in handling strange code constructs. I remember seeing a tutorial for writing a BASIC compiler that worked essentially that way.

In this case, the threaded code would maintain a FOR stack just like an interpreter. Executing FOR would initialise the loop variable, and place a frame on the FOR stack pointing to that variable, and listing the limit, the step, and the address of the code immediately following the FOR. Executing NEXT would pop FOR frames until the correct loop variable (if specified) was found, then increment the loop variable by the step, compare it against the limit, and conditionally GOTO the linked block. Threaded code is characterised by having most of the actual code in subroutines of a runtime library, and the program consisting mostly of parameter setup and JSRs.

Finally, the result of FOR X = 1 TO 0 tends to vary between dialects of BASIC. Some will iterate over 1 and 0 in that order, some will behave like C for(x=1; x <= 0; x++) and thus not execute at all, and some will behave like a do-while loop and execute only the 1 iteration.

The plot thickens...

First this code:



with these interpreters:

https://yohan.es/swbasic/

1
2
910

6800 FLEX BASIC

1
2
910

GWBASIC

1
NEXT without FOR in 900


Then this code:



with these interpreters:

https://yohan.es/swbasic/

1540

6800 FLEX BASIC

1
910

GWBASIC

1540


And then this code:



with these interpreters:

https://yohan.es/swbasic/

1540

6800 FLEX BASIC

1
1710

GWBASIC

1540


And finally this code:



with these interpreters:

https://yohan.es/swbasic/

1
2
1710

6800 FLEX BASIC

1
2
1710

GWBASIC

1
NEXT without FOR in 1700


Two different interpretations of "FOR I = 1 TO 0":

* find the next "NEXT"; that is the bottom of the loop
* the loop always executes at least once

It is interesting that GWBASIC only considers the first NEXT following the FOR to be valid.

I like the response of GW-BASIC best. It seems to get things closer to the way I'd expect. I come from a structured compiled basic background (VAX BASIC). I don't think your code would even compile under VAX BASIC, but the GW-BASIC is doing a fine job from a interpreter perspective. Have you tried it with MS PDS 7.1 or QuickBasic?

_________________
Bill

Hi!



Now you know why FastBasic does not have "GOTO"

There are many subtle results on typical BASIC interpreters. One is the "multiple NEXT", this runs in Atari BASIC:


The result is:


You can also abuse "POP" to call NEXT inside a GOSUB:


In the Atari computers, TurboBasic XL introduced "IF/ELSE/ENDIF" (without THEN), so this code is also valid:


There is a lot of BASIC code for the Atari computers full of those weird constructs and others like:
- Computed GOTO,
- Nested FOR with same variable, using POP to skip from one to the other,
- POP inside a GOSUB to return to grandparent instead of parent.

In FastBasic there is no line numbers and there is no "GOTO" nor "POP", but there is "EXIT" that terminates current FOR/WHILE/DO/REPEAT or exits a PROC, and you can't place the NEXT (or other loop ending) inside an IF or another loop. This makes the compiler a lot simpler and allows more optimizations on the generated code.

Have Fun!

Hi!



Your three examples in Atari BASIC:



TurboBasic XL, is compatible with Atari BASIC by default, but you can activate "enhanced FOR", this skips FOR with no iterations:


Have Fun!

I'll just leave this here:

It feels to me that a compiled Basic can either stay quite close to the semantics of the interpreted language, or aim to impose some degree of structure. In the absence of any block structure in the text of the language, there's no way to have a zero-iterations FOR loop without some form of compromise. And if you make that compromise, the behaviour of the compiled version will inevitably diverge from that of the interpreted version.

Like many things, it feels like a design choice, which is going to satisfy some people but not everyone.

The key, I think, is not to surprise the users too much. Document the behaviour!

(BBC Basic lacks a DO-WHILE for this very reason, I think: it has REPEAT-UNTIL which necessarily runs at least once through the loop, just as a FOR-NEXT must. And in both cases, the head of the loop sets up a return mechanism, so when a corresponding tail statement is met, it can go back to the top. And so there can be several such tails, and it doesn't matter where they are or how they are reached. This feels to me like a reasonable compromise, but then I am biased!)

The latest version of my BASIC torture code is:



Running it with https://yohan.es/swbasic/ yields:

1
2
910
1
2
1710

It appears that the NEXT statement "tells" the FOR statement the location of the bottom of the loop.

I don't get that impression at all. I believe that it's all in the spirit of what Chromatix stated above: NEXT doesn't modify anything inside the FOR activation frame, it simply accesses it to update the loop variable and perform a conditional branch back to the beginning of the loop (or discard the frame and fall-through from its current location). The location of whichever NEXT eventually terminates the loop determines the post-loop flow of execution via the fall-through mechanism, nothing more.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

This code would indicate otherwise:



1
2
7
8

Edit: On further thought, that is inconclusive. Let me think about it some more...

That result is totally expected in my scenario. In the BASICs I'm describing, FOR doesn't perform any increments or comparisons or branches, it just does an initial assignment, creates an activation frame and (always) proceeds with the following statement. That frame is never modified during the loop, but is discarded by whichever NEXT becomes the loop-terminator. NEXT is where all the "real" work is done, and the fall-through mechanism is its final task.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Technically, I guess we are both right. I am thinking like a compiler implementer.

Looking at this code:



---

My way:

Activation record contains:


init part of FOR statement does:


The iterate part is different depending on whether the loop counts up or down.

iterate part of an up counting FOR statement does:


iterate part of a down counting FOR statement does:


NEXT statement does:


---

Your way:

Activation record contains:


init part of FOR statement does:


iterate part of FOR statement does:


NEXT statement does:


---

Added complication: some BASIC interpreters allow leaving off the loop variable from the NEXT statement. For your way, NEXT would have to use indirection to get to the loop variable.

Further consideration, my way allows for easy optimization when the loop variable deals with integer instead of floating point values.