Code in TEST.BAS:

SIGNIFICANCE 11
MAP1 X(3),F

FOR X(2) = 1 TO 5
? X(2)
NEXT X(2)
END

COMPIL TEST/M/A/X:2
Yields: ?Syntax error (6) - NEXT X(2)

Why the syntax error?

PS: A-Shell/32/Windows Ver. 5.0.981.2

Tom -

It seems you have defined X as an array of (3) elements... X(3)

I don't think you can say

FOR X(2)=1 TO 5

Rather:

FOR Y=1 TO 5
?X(Y)
NEXT Y

Just a guess...

Actually, the problem is a limitation (which might well be considered a bug) in the allowed syntax for the argument to the NEXT statement. Under old Basic, it allowed an array element. With BasicPlus mode (/X:1 or higher), it apparently does not. I don't think there is anything new here - probably you are noticing this because you are switching to /X:2.

I can't think of any fundamental reason why NEXT X(2) shouldn't be allowed, so I'm inclined to issue a patch to fix it. However, I should point out a couple of things that might not be obvious about the differences between how FOR/NEXT loops worked under old Basic and how they work under BasicPlus (i.e. when the /X:# COMPIL switch used):

In the old compile and runtime mode, FOR/NEXT loops were handled by the runtime interpreter in such a way that they always executed at least once, and there were no limitations on the position of (or even number of) NEXT statements associated with a FOR statement. (This allowed for some pretty awful programming styles.)

In BasicPlus mode, FOR/NEXT loops are handled by the compiler, essentially converting them into more primitive statements (IF, GOTO, etc.).

Some consequences of these differences:

1. With BasicPlus mode, the conditional test occurs at the top of the loop, so a loop can execute zero times. (It always executed at least once under old Basic.)

2. With BasicPlus mode, there can only be one NEXT for each FOR, and if nested, they have to match up in the same way that IF and ENDIF statement do.

3. With BasicPlus mode, the argument to the NEXT is really just a formality, since it essentially is converted to a GOTO back to the top of the loop. (This is one reason why it makes little sense to complain about your syntax.) In old Basic, the argument was significant, both because the increment and test was done on the NEXT, but also because in the case of nested loop,s the variable specified allowed the runtime system to figure out which FOR the NEXT went with.

4. On the other hand, with BasicPlus mode, the variable you specify in the FOR statement is actually used directly for the incrementing and testing of the loop limits. For this reason, unless you are secretly working for Intel or AMD to encourage CPU usage, it doesn't make much performance sense to use an array variable for the loop variable. (It takes several times more effort to evaluate an array variable than a simple one.)

5. In BasicPlus mode, you are allowed to use I variables for the loop counter (whereas F was required for old Basic). So if efficiency is the goal, you should use a simple integer (I2 or I4) variable for the loop counter.

That said, it's on the to-be-fixed list.

Thank you AND no hurry.

Yes, I am just starting to use /X:2.

I use array variables in for-next loops when navigating large arrays (greater than 3 dimensions).

According to the AlphaBASIC PLUS User’s Manual, Rev 02: The FOR and NEXT statements initialize and control program loops. A loop is a structure in which the same statement or statements can be performed a specific number of times. Whether or not a loop is executed depends upon the value of the control-variable. The control-variable may even be subscripted. It can be either a six-byte or an eight-byte floating point variable, a 4-byte integer, or a single alphabetic string character, such as ’a.'

Touché. Indeed, it must be fixed.

(I'm not sure about the alphabetic character option though. That's an interesting feature, but is likely to require some special consideration since in Basic, due to the overloading of the + operator, A$ + N is going to concatenate the string representation of N to the end of the A$ string, rather than "increment" it. So additional logic would be needed in the increment operation, i.e. A$ = chr(asc(A$)+N). And that would probably require another battery of testing to make sure there were no side effects on the existing loop logic, which I'd prefer to avoid prior in 5.0. I'll add that to the 5.1 list...)

I think a string variable used as the counter in a for-next loop is just wrong on so many levels. Please do not consider it an option for 5.1 or anytime in the future. I am looking forward to numeric array variables used as counters in 5.1.

...and we thank you for your kind support.

Thank you for your good sense in rejecting the string idea. To show my appreciation, the NEXT X(2) "feature" is already implemented, in 981.4, which will be posted tonight.

FYI: After adding /X:2 to my compile I noticed that when the INDEXED'STATS command was executed it returned truly LARGE numbers (and correspondingly LARGE allocates). A quick call to Jack after hours (Jack, thank you VERY MUCH for your GREAT support!) determined that the Alpha Basic Plus-Isam Plus combination returns integers not binaries. By switching all the binary numbers to integers the problem was resolved. Who'd have thunk Alpha Micro would throw such a curve ball