Is this a bug or am I crazy?

[Eddie]

Dim As Integer x
x = 0
For x = (x+2) To (x+7)
?x
Next
?"---"
?x
?" "
x = 10
For x = (x-2) To (x-7) Step -1
?x
Next
?"---"
?x
sleep

Outputs:

2
3
4
5
6
7
8
9
---
10

8
7
6
5
4
3
2
1
---
0

When I was expecting:

2
3
4
5
6
7
---
7

8
7
6
5
4
3
---
3

I guess I shouldn't use the same variable on both sides of the equal sign but still, Is this intended? Even when I use different variables it still adds (or subtracts) one after it leaves the FOR...NEXT loop:

Dim As Integer x,n
x = 0
For n = (x+2) To (x+7)
?n
Next
?"---"
?n
?" "
x = 10
For n = (x-2) To (x-7) Step -1
?n
Next
?"---"
?n
sleep

[Imortis]

This is intended. From the manual:

The For statement causes the execution of the statements in the statement block until iterator compares greater than endvalue (or less than endvalue if stepvalue < 0).

Also, please use the code tags when posting code as it make things easier for everyone to read.

[fxm]

Because the iterator is internally incremented/decremented just before testing the exit value, at the end of the loop block, like the [Do...Loop] block below:

Code: Select all

Dim As Integer n

For n = 1 to 9
  'user code
  Print n
Next n
Print "after looping: " & n
Print

n = 1
Do
  'user code
  Print n
  n = n + 1
Loop Until n > 9
Print "after looping: " & n

Sleep

[jj2007]

prints 2...9:

Code: Select all

x = 0
For x = (x+2) To (x+7)

Actually, like Eddie, I would also have expected that it prints 2...7. It's an implementation issue. Bug or feature? No idea, but the quote from the manual is not clear enough IMHO: "until iterator compares greater than endvalue" would mean an endless loop in this case, because x is always lower than x+7, isn't it...? English is a tricky language ;-)

[fxm]

Firstly, calculation of the start value:
x = x + 2 = 0 + 2 = 2
Secondly, calculation of the exit value:
exit_value = x + 7 = 2 + 7 = 9
Then, start looping

During the loop, the exit value is not updated.

[jj2007]

Firstly, calculation of the start value:
x = x + 2 = 0 + 2 = 2
Secondly, calculation of the exit value:
exit_value = x + 7 = 2 + 7 = 9

I have no doubt that it has been implemented like that. Equally logical, natural, whatever adjective you want to use to defend this choice:

Firstly, calculation of the start value:
x = x + 2 = 0 + 2 = 2
Secondly, calculation of the exit value:
exit_value = x + 7 = 0 + 7 = 7

It's a rare case, of course, so it is understandable that this behaviour is not properly documented. How do other languages behave?

YaBasic:

Code: Select all

ct=0
for ct=ct+2 to ct+7
  print ct
next

Prints a "2" and stops

SmallBasic:

Code: Select all

n=0
for n=n+2 to n+7
  print n
next n

Endless loop

MasmBasic:

Code: Select all

  For_ ct=ct+2 To ct+7
	Print Str$(ct), " "
  Next 

2 3 4 5 6 7

Javascript:

Code: Select all

var i=0;
for (i = i+2; i < i+7; i++) {
    text += i + "<br>";
}

Hangs and freezes the browser

Python 3:

Code: Select all

x=0
for x in range(x+2, x+7):
    print(x),

2 3 4 5 6

C:

Code: Select all

  int i=0;
  for (i=i+2; i<i+7; i++) printf("%i ", i);

Endless loop

O2Basic:

Code: Select all

for x=x+2 to x+7
  print x
next

2 3 4 5 6 7 8 9 (hey, this looks logical because it looks like the FreeBasic output!)

Liberty Basic:

Code: Select all

      for x=x+2 to x+7
        print x
      next

2 3 4 5 6 7

[MrSwiss]

It's a rare case, of course, so it is understandable that this behaviour is not properly documented.

It is a logical ERROR!

Just because of a logical error, it doesn't automatically mean,
that it is 'incorrect' ... Btw: fxm's calculation is 'logically' correct.

Inside: For ... Next, the start/stop values are treated as constants,
as well as, the: increment/decrement (aka: Step value)

[jj2007]

It is a logical ERROR!

Judging by my short collection of dialects in the previous post, it seems there are as many "logics" as there are language developers around ;-)

[fxm]

Always the same logic, even with stepvalue:

Code: Select all

Dim As Integer x
x = 0
For x = (x+2) To (x+7) step x
?x
Next

Sleep

Code: Select all

 2
 4
 6
 8

[MrSwiss]

... it seems there are as many "logics" as there are language developers around ;-)

Nope, it rather seems to me, that people aren't reading Documentation:
e.g. "how are expressions evaluated"or "Operator Precedence" and similar. ;-)

[fxm]

Proposed documentation update:

The values of stepvalue and endvalue are stored internally immediately following execution of the For statement and thus neither can be changed inside the For loop.

Following execution of the For statement, the iterator is initialized to startvalue, then values of stepvalue and endvalue are evaluated and stored internally (thus neither can be changed inside the For loop), and finally the loop is started.

[jj2007]

Always the same logic, even with stepvalue:

Yes indeed. There is no doubt that this logic has been applied. But, as demonstrated above, it is not a "natural" logic. Other language developers apply a different logic. Eddie applied a different one. Me too btw, but I am not a religious guru who will force my divine logic on you. I am just pointing out that what FB developers have done, consciously or not, is a choice, and maybe should be documented as such. Your proposal is OK but still ambiguous. Try this:

Following execution of the For statement, the iterator is initialized to startvalue, then values of stepvalue and endvalue are evaluated (taking changes to iterator into account) and stored internally (thus neither can be changed inside the For loop), and finally the loop is started.

[MrSwiss]

Why don't you use my "internally treated as constants" which makes it clear,
that changing them, isn't possible, once set ...

[fxm]

Your proposal is OK but still ambiguous. Try this:

Following execution of the For statement, the iterator is initialized to startvalue, then values of stepvalue and endvalue are evaluated (taking changes to iterator into account) and stored internally (thus neither can be changed inside the For loop), and finally the loop is started.

I do not agree with your adding because normal people who do not have the unfortunate idea of putting the iterator itself in the expressions starvalue / endvalue / stepvalue will be disturbed by it.
I thing that the ', then ... evaluated' term is sufficient.

[counting_pine]

I think it should just say that the order of these three activities is undefined:
- evaluating the start value
- evaluating the end value
- initialising the iterator

I would say that the most intuitive ordering is the one given above, but it would potentially require using a temporary variable to store the start value before the iterator is initialised.

Because FBC doesn’t perform them in the most intuitive order, I would say that well-written code should not make any assumptions about the ordering, and so it should avoid referring to the iterator when setting the start/end values.