World: r4wp

well, I can imagine more scenarios, and it needs some thought to 
stay consistent between the cases. So my first thoughts, starting 
with the latest example:

for i 2 1 1 [prin "x"]


If above scenario means returning #none (and I agree with that), 
then I think that the for i 1 2 0 [print "x"] could be just the same. 
But - it might be related to the thoughts of the indexing. In REBOL 
series (if I am right), the position is in between the elements (not 
on the first element). So in that regards, skip 0 moves nowhere. 
But - it might also mean (as "first series" returns first element), 
that it should perform the loop just once. 


The last option for me is to cause an infinite loop, although from 
some point of view, it might make some sense too - you simply want 
to traverse the range, from 1 to 2, but you skip 0. If you would 
use just 'skip, you would cause an infinite loop. So - I really don't 
know ....

Well, I do not require you to invent or justify how it should work. 
I think that it really may be just a matter of preference. So, you 
just need to tell what it is you would find the most convenient behaviour 
when writing the

    for i 1 2 0 [prin "x"]

in your code.

Of course, there is an option that you just do not mind, since you 
do not intend to write such an expression at all.

(actually, in that case you might prefer the interpreter to cause 
an error for you to inform you that you did something you did not 
intend to do)

I prefer at least one execution.  If 0 is the loop increment, then 
it is a forever loop unless the loop parameters are also both 0

Thanks, Graham, counted.

so for i 0 0 0 [ .. executes only once ]

Aha, hmm, that is a problem. If

    for i 1 2 0 [prin "x"]

loops forever, I would expect that e.g.

    for i 1 1 0 [prin "x"]

behaves exactly the same way looping forever as well.

execute once, increment the loop counter and then check it against 
the upper bounds.

Yes, but it is in the bounds still.

so, in the first instance it's forever, the second is just once

You cannot get out of bounds adding 0.

>= to the upper bound

so that would be two iterations

hmm.. what happens with negative increments

so that would be two iterations
 - if I understand it well that looks like a preference shift.

execute once, increment counter from start, if counter is <= outer 
bound execute again.  if counter is now >= outer bound exit

we are allowed to alter the counter value inside the loop right?

if counter is now >= outer bound exit

 - however, that requires to use two distinct tests for iterations 
  (in the first case the upper bound is included in the range since 
 upper-bound <= upper-bound, while in the second test the upper bound 
 is excluded from the range since upper-bound >= upper-bound)

that would allow us to break out of a forever loop

Yes, we are:

* allowed to use BREAK
* allowed to change the cycle variable inside the body

So, a forever loop is not a problem when you do not think it is a 
problem

Regarding the negative bump versus the positive bump:


* I tend to think that the set of integers specified by start-bound 
1 end-bound 3 and bump 1 to contain the numbers [1 2 3] 

* I tend to think that the set of integers specified by start-bound 
3 end-bound 1 and bump -1 to contain the numbers [3 2 1]

* judged this way the set of integers specified by start-bound 1 
end-bound 3 and bump 0 may be considered
** incorrectly specified (cause error)

** empty since it does not specify correctly a nonempty set of integer 
numbers (do not loop)
** it may be specially defined as [1 2 3] (infinite loop)


Choosing an alternative of the above three I consider just a matter 
of preference.

In many other languages it leads to infinite loop.

It looks like (on R3) it checks the upper bound if the bump value 
is positive, lower bound if the bump value if negative
AND if the bound value can be reachable with the bump value.

for i 5 3 0  [i: 2 print i] ;==2, stop
for i 5 3 0  [i: 6 print i] ;==6, infinit

this is not consistent with 
>> for i 3 5 0  [i: 6 print i] ;== none
>> for i 3 5 0  [i: 2 print i] ;== none

Yes, that is the inconsistency described above.

in the first example, it checks the right-bound-value.

So if the bump value is zero, then it should check;
* always the right-bound
* or the lower one.

>> for i 5 5 0  [i: 2 print i] ;==2, stop.

I mean "decide the direction by looking at the bounds" then "check 
the bump value, if it is possible to reach that bound value (check 
the direction of bump value)"

if it is not reachable, return none without executing the block.

This can cover all the possibilties, pos., neg. or zero bump value.

I understand you, and youi gave some inspiration, but you used some 
terms that may be rather confusing:

right bound
 - did you mean the END value?
lower bound
 - did you mean the START value or the minimum of START and END?

Yes that was what I mean, sorry, English is not my main language, 
so it is a bit difficult what I exactly mean.

No problem, I just wanted to make sure.

this still leaves an uncertainty whether we want to handle the situation 
of

    for i 1 2 0

the same as

    for i 1 1 0

BTW, END and START I did not mean as English words. I meant them 
as the respective FOR parameters.

according to my explanation, both should return none, because end 
value is not reachable.

hmm, but 1 = 1 + 0, i.e. the END value actually is reachable in the 
latter case

Yes, if step is negative START - END should be swapped.

aha, second case, you are right.

wait, it should pass the END value.
For i=1 To 1 Step 0 --> infinite loop on  BASIC.

Normally, in old BASICs languages, variable used in FOR, its value 
stays END+1 at the end of the loop.

* end_value + step_value

Hmm, that is not convenient in some cases

There is another issue;
on R3:

for i 1 3 0.2  [print i] ; prints 1 ... 2.8 (end value is not included)

for i 3 1 -0.2 [print i] ; prints 3 ... 1.2 (end value is not included)
on R2:

for i 1 3 0.2 [print i] ; prints 1 ... 3 (both start & end value 
included)

for i 3 1 -0.2 [print i] ; prints 3 ... 1 (both start & end value 
included)

I think R2's behaviour is "more" correct.

for i 1 3 0.2  [print i] ; prints 1 ... 2.8 (end value is not included)

 - this is an arithmetic problem; 0.2 is not representable exactly 
 by a binary floating point (i.e. decimal!) value.

I do *not* recommend to use a general code for such loops